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1 PP introduction 

1.1 Introduction 

Based on the advice of the commission Electronic Voting at Polling Stations dedicated Protection 
Profiles have been developed for two devices that can be used to support the voting process. Namely 
these devices are the ballot printer and the vote counter. They can be used by the voter to make their 
choice and print it on a ballot paper and to efficiently count the votes. 

The current document represents the Protection Profile for the vote counter. 

In order to provide a global overview of the process, the current document contains information on 

• The procedural view to voting and counting 

• The life-cycle of the vote counter 

• Assets to be protected by the vote counter 

• Subjects that are interacting with the vote counter 

• Threats against the assets 

• Organizational Security Policies to be fulfilled 

• Assumptions that can be made about the intended environment 

The whole content of the current document has been discussed and documented based on the 
principles for voting.. These are as follows: 

• Transparency 

• Verifiability 

• Integrity 

• Eligibility to vote 

• Freedom of vote 

• Secrecy of the vote 

• Equal sufffage 

• Accessibility 
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120 1.2 PP Reference 

Title: 

Contact: 

Version: 

Authors: 

Registration: 

Certification-ID: 

Evaluation Assurance Level 

CC-Version: 

Keywords: 

121 1.3 Speciflc terms 

122 The following specific terms are used in the context of this document 


Term 

Description 

Voter 

In the context of this document, the voter is regarded as a person that is legitimated 
to participate in an election. 

Choice 

The choice of the voter is the primary asset of the ballot printer. The choice means, 
on the one hand the selection of a party and a candidate, or the answers to the 
question for a referendum, or a blank choice on the ballot printer (see figure 1). 

Vote 

From the moment the ballot paper is in the ballot box, in the context of this 
document it is regarded and described as vote. The vote is the primary asset of the 
vote counter. 

Mode 

Modes are dedicated life-phases where the TOE requires or offers interaction. 


123 Table 1: Specific terms 

124 


Protection Profile for a Voting System Vote Counter 

Draft 

The assurance level for this PP is EAL 4 augmented. 

Voting System, Vote Counter 
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126 1.4 TOE OverView 

127 1.4.1 Introduction 

128 The TOE defrned in this Protection Profile is the vote counter that can be used within an election 

129 process. In the following chapters, the overall election process that is supported by the vote counter is 

130 described. 

131 1.4.2 Procedural OverView 

132 A simplified overview shows the process as follows: The voter comes to the polling station and 

133 legitimates himself as a legitimate voter against the members of the electoral committee, e.g. by 

134 presenting their voter card and their identity document. The members of the electoral committee admit 

135 the voter to vote. For that the voter is given the possibility to make a vote choice with the ballot printer 

136 and print that choice. After the voter has checked whether their choice has been printed correctly on 

137 the ballot paper (every print on the paper shall be only plain text that is readable by everyone) the 

138 voter puts their choice into a classical ballot box. In the moment where the choice is put into the ballot 

139 box, it becomes a vote. 

140 Once the voting has ended the count starts. In this phase the electoral committee performs several 

141 actions including the counting of the votes deposited in the ballot box. Before opening the ballot box 

142 the electoral committee shuts down the ballot printer so that this device cannot be used anymore in the 

143 polling station. The ballot papers can then be counted with the vote counter. The vote counter prints 

144 the result of the counting and this printout is then attached to the official report. The count phase ends 

145 with drawing up an official report by the electoral committee. 

146 lt is important to understand that the procedure as it is described in this document differentiates 

147 between the voter’s choice and the vote. The choice in this context means, on the one hand the 

148 selection of a party and a candidate on the ballot printer or the selection of an answer to a referendum 

149 question or the selection for a blank vote, but also the printout itself until it is put into the ballot box 

150 (see figure 1). Thus, this document always refers to the term “choice” to describe the voters’ activities 

151 until they put their ballot paper into the ballot box. From the moment the ballot paper has been put into 

152 in the ballot box, in the context of this document it is regarded and described as a vote. 

153 The paragraphs below provide a more detailed overview of the ballot printer and vote counter as well 

154 as of the voting process at all. 

155 The following figure summarizes the cooperation of the components from a high level perspective. 
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Figure 1: System overview 


1.4.3 Detailed overview 

From a procedural perspective, it can be distinguished between the phases of voting and counting that 
are described further within the following chapters. 


1.4.3.1 Set up 

Before the voting begins the ballot printer needs to be set up (see figure 2).This comprises the placing 
in the polling station and the connection to electricity. A member of the electoral committee starts-up 
the ballot printer. He/she shall legitimate and process the start-up by a digital token. The ballot printer 
requires a self-test and the printout of one or more choices to see whether the ballot printer works 
correctly. lf the electoral committee decides that the ballot printer works correctly the ballot printer is 
ready for use. The following diagram depicts the set up process of the ballot printer. 
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sd Preparation J 



Figure 2: Start process for the ballot printer 

1.4.3.2 Voting 

On the day of the election, the polling station opens at the time that is defmed by electoral laws. A 
voter that wants to vote, hands over their voter pass and shows a valid ID-document to the electoral 
committee. In case of multiple elections on the same day, the voter hands over a voter pass for each 
election the voter is entitled to vote for. The electoral committee checks the voter pass(es), checks if 
the voter pass is not on the list of invalid voter passes and checks based on the ID-document if the 
person that wants to vote is the rightful holder of the voter pass(es). If all these checks are successfïilly 
completed, the electoral committee gives the voter one or more tokens to activate the ballot printer to 
make a vote choice for the election(s) the voter is entitled to. The voter receives a token for each 
election the voter is entitled to cast a vote for. A voter can, in addition to his own vote, cast one or two 
proxy votes. The proxy votes may only be cast when the voter casts his own vote. For a proxy vote the 
voter must hand over the voter pass of the proxy giver. On the voter pass the proxy part must have 
been filled in completely and both proxy giver and proxy receiver must have signed the voter pass. 
The proxy receiver must also present a copy of an ID-document of the proxy giver. 

The voter shall present a token to the ballot printer. The ballot printer swallows the token so that the 
token can only be used once each time it is handed over to a voter by the electoral committee. The 
token will activate the ballot printer for the election the voter can make a choice for and guide the 
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voter through the steps. 

Once the voter has made his/hers choice, they will be asked to confirm their choice. In case that the 
voter confirms their choice, the printer prints the choice on a ballot paper. In the case that the voter 
does not confirm the displayed choice, the voter can go back in the selection process. After the choice 
of the voter has been printed the choice made by the voter is deleted from memory. 

The voter withdraws the printed ballot paper from the ballot printer and puts the ballot paper in the 
ballot box. The following diagram depicts the voting procedure. 


sd VotingT ^ 



Figure 3: Voting process 

Tokens can be re-used by the electoral committee for next voters. To re-use tokens the electoral 
committee can collect the tokens that have been swallowed by the ballot printer. 

To terminate the voting process, the electoral committee shuts down the ballot printer. 
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Figure 4: Shut-down of the ballot printer 

1.4.3.3 Counting 

The voter counter shall be started by a token. The vote counter shall request the number of the polling 
station or of the ballot box to be entered or a previously set number to be confirmed before it performs 
its self-test and enters the mode that allows the beginning of the counting process. 

During the counting process, for each scanned ballot paper where the vote is recognized the vote 
counter shall print a consecutive number on the ballot paper. Furthermore it shall save the recognized 
vote and printed number of every single ballot paper to its log file. When the ballot papers of a ballot 
box have been put through the vote counter the person that is allowed to operate the vote counter shall 
confirm this. The counter generates a result of the ballot papers that have been counted and a result 
(the number of) of the ballot papers that have been rejected because they could not be counted. The 
results can be printed on paper and can be stored on a digital token. The electoral committee will judge 
the ballot papers that have been rejected by the vote counter. In the case that the vote counter was able 
to recognize the vote on the ballot paper and that the consecutive number has been printed, the vote 
counter shall put this paper in an output tray for successfully counted ballot papers. It shall not put 
successfully counted ballot papers into a tray for ballot papers that caused problems during the 
scanning process. The other way round, the counter shall put votes that could not be counted into a 
tray for those papers and shall not put them into a tray for successfully counted votes. The following 
diagram depicts the process of counting. 
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Figure 5: Counting the votes 
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1.4.4 TOE type 

The TOE described in this PP is a counter (vote counter) that is used to count ballot papers within an 

election process. 

1.4.5 TOE physical scope 

The physical scope of the TOE comprises the hard- and software that is relevant for the iunctionality: 

• Casing of the Device: The casing of the vote counter needs a mechanism to protect the device 
ffom intrusion. The ballot vote counter may consist of more than one part. In that case each 
part shall have its own casing that protects it trom intrusion 1 . 

• Interface(s) for token: The TOE provides one or more interfaces that are used for token based 
role holder authentication. 

• Interface(s) for data transfer: The TOE provides one or more interfaces that are used for 
data import and export (election data, token data, configuration data, log-file, counting 
results). 

• Interface(s) for user-interaction: The TOE presents activated users the set of interactions 
they are allowed to perform and guides the user through the process. 

• Scanner: The TOE includes a scanning unit that is able to scan the ballot paper. 

• Processing unit: This unit is responsible for processing the counting and all related processes. 

• Output tray(s): The TOE provides Output tray(s) that allows the sorting of scanned ballot 
papers. 

• Printing part: The TOE provides a printing unit that is able to print control lines on the ballot 
papers and to print the counting result. 

• Security Module: The TOE includes a security module that shall be used as a cryptographic 
service provider (it provides key generation, key destruction if required and signature 
generation) 2 


1 Some of the requirements in this Protection Profile are dedicated to the case that the TOE may comprise more 

than one physical part/unit. 

2 The functionality of hashing and signature verification is however provided by the TOE itself. 
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Vote counter/ Physical scope 


Casing of the device 


Scanner 


Interface fortoken 


Processing unit 


Interface(s) for data transfer 


Interface(s) for user-interaction 


security module 
(not part of the TOE) 


Printing part with output trays 


Figure 6: TOE physical scope 

Although built into the TOE, the security module itself shall not be part of the TOE. For security 
modules Standard Protection Pro files exist and CC practise is to re-use these and extend them with the 
additional features and the evaluation level needed. This means that a security module is built in the 
casing of the TOE and is intemally connected to the TOE, but has to be evaluated separately and not in 
the context of the evaluation of the vote counter. This kind of illustration has been chosen to point out 
that the security module shall be an intemal component that is placed within the casing of the TOE. 
The security module shall be evaluated according to [PP SM], 


1.4.6 TOE logical scope 

The logical scope of this TOE can be defined by its security functions: 

• Token authentication and activation: The TOE is able to authenticate presented token, match 
token to a defined role and activate dedicated role functionality. 

• Protection of integrity and authenticity: Within the whole process, the TOE is able to protect 
data in terms of integrity and authenticity. 
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• Cryptography that allows the verification of signatures on data to be imported by the TOE 
and signing of data, that can be exported. 

• Management: The TOE provides the functionality to manage on the one hand the data that is 
used for the operation of the TOE (election data) and on the other hand security related data 
(log-file access, configuration, token management, counting result). 

• Auditing: The TOE audits and stores defmed events and provide the functionality to export 
the audit logs and to delete them. 

• Self-Protection: The TOE shall be able to detect whether its hard- or software has been 
manipulated. In the case that the self-protection mechanism detects an intruder, it shall notify 
users and switch to a secure state. 

• Self-Test: The TOE is able to perfomi a self-test to check, whether the TOE works as 
specified and allow authorized users to verify the integrity of data, software and hardware. 


276 The TOE uses cryptography that allows the verification of signatures to verify imported data and 

277 signing of data to secure exported data. The signing of data is provided by a security module, hence it 

278 is not a part of the logical scope of the TOE. See paragraph 1.4.5. 


279 1.4.7 TOE Life-cycle 

280 The following figure shows the life cycle phases for the vote counter. 
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Figure 7: Life cycle for the vote counter 


Life Cycle Phase 

Description 

Specification 

During the specification-phase, the public body that is responsible 
specifies the requirements that the vote counter shall fulfill. This 
includes the development of the Protection Profiles for the vote 
counter. 

Development 

Based on the specification, the manufacturer is responsible for the 
development of the vote counter in a way that it matches the 
requirements of the specification. Thus, this phase begins when a 
manufacturer is awarded the contract for the development and ends 
when TOE samples have been successfully released. 

Additionally, the vote counter returns ffom other phases back into the 
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Life Cycle Phase 

Description 


development, when the specification has changed and the 
manufacturer needs to update the devices. 

Certification 

This phase comprises the evaluation of the TOE samples by an 
evaluation body for Common Criteria and the certificated by a 
certification authority. 

Production 

After the certification of the TOE samples, the production of the vote 
counter starts. The manufacturer shall ensure that compared to the 
TOE samples no component of the vote counter is changed in any way 
whatsoever during the whole process of production. 

Qualification 

The qualification of every produced vote counter by an independent 
evaluator ensures that the produced vote counters are consistent with 
the evaluated and certified TOE samples. 

Delivery 

Once the devices have been qualified, an Authority for distribution 
distributes the devices to the municipalities. 

Long Term Storage 

After their distribution to the municipalities or after an election, vote 
counters require a secure long time storage at the Municipal 
authority to ensure that they cannot be manipulated. 

Prepare for use 

The preparation of the vote counter comprises the configuration of 
election options (e.g. parties and candidates) as well as a test of the 
devices whether all components work correct. The configuration shall 
be done by the (de)Configurator. 

Storage after configuration 

After configuration, the Municipal authority will store the systems in 
a secured area that the municipal authority has designated for this 
puipose. 

Delivery to polling station 

The Municipal authority will transport the systems to the polling 
station. 

Startup init 

The startup of the vote counter on the day of the election is done by 

the vote counter operator. 

Operation 

In its operational phase, the vote counter is started by the vote 
counter operator and used to count the votes. Once the counting has 
ended, the vote count operator shuts the vote counter down. 
lf during operation a vote counter’s self-protection mechanism 
registers a manipulation or defect then the vote counter will go the 
“Frozen”state, both to prevent the vote counter fforn being used for 
counting ballots and to protect the information contained therein. 

Frozen 

After the election, configuration data, logs and counting results shall 
remain in the vote counter until the result of the election is confirmed 
by the Central electoral committee or in case a criminal 
investigation has been initiated, after that investigation has been 
completed. 

Delivery to storage 

The Municipal authority will transport the systems ffom the polling 
station to a secured storage location(s) that it has designated for this 
puipose. 

Storage after usage 

After the voting, the Municipal authority will store the systems in a 
secured area that it has designated for this purpose. lf the central 
electoral committee decides that a new vote is necessary, the 
municipal authority will transport the systems back to the polling 
station again. 
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Life Cycle Phase 

Description 

Investigation (optional) 

In case of malfunction, manipulation or suspicion of malfunction or 
manipulation, the vote counter needs to be investigated. This 
investigation will be done by an authority for investigation. 

Deconfiguration 

After the central electoral committee has confirmed the outcome of 
the election the (de)Configurator deletes the counting data, election 
data and logs from the devices. The devices are then transferred to 
long-term storage. 

End of life 

In this phase, the Manufacturer destroys the vote counter in a way, 
that it cannot be used again and that all data is deleted in a secure way. 


284 Table 2: Life-cycle phases and their description 

285 1.4.8 TOE Modes 

286 The life cycle phases can be grouped into dedicated operational modes according to their required 

287 functionality. This allows the available functions of the modes to be reduced to the required minimums 

288 and reduces the likelyhood of security violations. Furthermore the limitation to a predefmed sequence 

289 of modes helps to satisfy the security requirements that are implemented in the vote counter. For the 

290 vote counter the following operational modes have been defined: 

291 • Election 

292 • Management 

293 

294 The relation between the life-cycle phases and the modes is shown in Table 3: 


TOE mode 

TOE life-cycle phase 

Election 

“Operation”, 

Management 

“Delivery”, “Long Term Storage”, “Prepare for user”, 
“Storage after configuration”, “Delivery to polling 
station”, “Startup”, “Frozen”, “Delivery to storage”, 
“Storage after usage”, “Investigation” and 

“Deconfiguration” 


295 Table 3: Relation between TOE modes and life-cycle phases 

296 The possible sequence of modes are depicted in Figure 8. In order to activate the “Election” mode it is 

297 necessary to present a token that is assigned to a role that is allowed to change the mode of the TOE. 

298 Note: The TOE mode “Election” is not persistent, i.e. will change to “Management” in case of a 

299 shutdown of the system or power supply failures. 
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Figure 8: TOE mode diagram of the vote counter 


Every mode has the following two authentication sub States: 

• NOT AUTHENT1CATED: TOE has been powered on, no token present. 

• AUTHENT1CATED: TOE has been powered on, role holder token authentication has been 
performed successfully. 

The TOE is not aware of the following life-cycle phases: 

• Specification 

• Development 

• Certification 

• Production 

• Qualification 
Application Note: 

The TOE starts to exist after production and qualification. During qualification all TOE modes are 
available and tested. Table 3 shows the relation between the defmed TOE life-cycle phases and TOE 
operational modes. 


1.4.9 Authentication Token 

The token to activate the modes and to gain access to the vote counter for administrative tasks is not 
part of the TOE. For such authentication tokens Standard Protection Profiles exist and CC practise is to 
re-use these and extend them with the additional features and the evaluation level needed. The 
activation tokens shall be based on devices that have been evaluated according [PP-AM], 

1.4.10 TOE data structure 

The data that is used by the TOE can be divided into two main parts: 

• User data 

• TOE Security Functionality (TSF) data 
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TOE data structure 


User data 


TSF data 

Objects: 


- log 

-votes 


- token data 

- counting data 


- configuration data 

- ephemeral data 


- time 


Figure 9: TSF data structure 

User data: 

User data refers to the data that is processed by the vote counter and that has to be protected in terms 
of integrity and authenticity. The user data in this context is limited to the votes, the counting results 
and the ephemeral data associated with it. 

lt should be noted that the system of authentication of the TOE is based on tokens. Those tokens are 
treated as users even though the TOE will never get hold of the real user identity. 

TSF data: 

Refers to all other data that are necessary to operate the TOE. All of the other data does not belong to a 
dedicated user but is necessary to guarantee the functionality of the TOE, hence is summarised as TSF 
data. The following list of TSF data summarizes the information that is used in the context of this PP. 
Note however that this list does not claim to be complete. 

• The log file 

• Information about the authentication token (i.e. the link between the token 1D and the role, 
public keys) 

• Configuration data for election 

• The time 
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346 2 Conformance Claims 

347 2.1 Conformance statement 

348 This PP requires strict conformance of any PP/ST to this PP. 

349 2.2 CC Conformance Claims 

350 Thi s PP has been developed using Version 3.1 Revision 4 of Cormnon Criteria [CC]. 

351 This PP claims conformance to [CC] part 2 extended. 

352 Thi s PP claims conformance to [CC] part 3 extended. 

353 2.3 PP Claim 

354 This PP does not claim conformance to any other PP. 

355 2.4 Conformance claim rationale 

356 Since this PP does not claim conformance to any Protection Pro file, this section is not applicable. 

357 2.5 Package Claim 

358 This PP is conforming to assurance package EAL6 as defined in [CC] Part 3 augmented by the use of 

359 ALCDVS.2, AVA VAN.5 and an explicitly drafted assurance component, ALCDEL.2. 

360 The SFRs in this PP form a functional package “vote counter functionality” and use SFRs ffom part 2 

361 of CC plus one extended component named FDP FPC. 1. 
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3 Security Problem Definition 

The Security Problem Definition (SPD) is the part of a PP, which describes 

• the external entities that are foreseen to interact with the TOE, 

• the assets which the TOE shall protect, 

• the assumptions on security relevant properties and behaviour of the TOE’s environment, 

• threats against the assets, which shall be averted by the TOE together with its environment, 

• operational security policies, which describe overall security requirements defmed by the 
organisation in charge of the overall system including the TOE. 

3.1 External entities 

The following external entities are allowed to interact with the vote counter in dedicated modes. Those 
roles have been defmed for the use in this Protection Profile. 


Role 

Description 

(de)Configurator 

The central electoral committee for an election decides on the 
admission of lists that can participate in an election and the admission 
of the candidates that can be put on the lists. The admitted lists and 
candidates and the admitted question(s) for a referendum are 
published. 

The (de)configurator shall check the vote counter before being used 
during the ballot. The checks that the (de)configurator needs to 
perform includes (but are not limited to): 

• Checking the version of the software 

• Conducting a self-test, including a check of the security of the 
vote counter 

• Checking the integrity of the hardware, software and data 

After these checks have been successfully perfomied the 
(de)configurator uploads the list of parties and candidates or the 
question(s) for a referendum the vote counter requires in the electon 
mode. The role is also responsible for additional configuration data 
that is required by the TOE. The (de)configurator then performs a 
functional test. 

The vote counter maintains a log file with stored audit events. 

The (de)configurator is allowed to read and export the information 
trom this log file and other data that is relevant for analysis. 
Furthermore it falls into the responsibility of the (de)configurator 
authority to delete the election data after the central electoral 
committee has announced the outcome of the election or - in case a 
criminal investigation has been initiated -, after that investigation has 
been completed. 

Vote Counter Operator 

The Vote Counter Operator is responsible to start up the vote counter 
when it is needed for counting. 

The Vote Counter Operator is allowed to export the counting result. 


374 Table 4: Roles used in the Protection profile 


362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 
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375 3.2 Assets 

376 


Asset 

Description 

Need for Protection 

Vote 

From the moment the ballot paper has been put 
into the ballot box, in the context of this 
document it is regarded and described as vote. 

As soon as the printed choice has been placed into 
the ballot box, there is no further need to protect 
the confidentiality of the vote. 

It must be ensured that a vote is counted and only 
counted once during one count process (as 
described in chapter 1.4.2). 

• Integrity 

Logs 

The vote counter maintains a log. 

Logs must be protected in terms of integrity and 
authenticity. It is however required that log files 
in the devices are securely deleted as soon as the 
results of an election process have been declared 
or in case a criminal investigation has been 
initiated, after that investigation has been 
completed. 

• Integrity 

• Authenticity 

Configuration 

data 

The configuration data contains information about 
the upcoming election or elections (if more than 
one election takes place on one day) that is going 
to take place or is taking place that the vote 
counter has to be used in. It also comprises the list 
of parties and list of candidates or the referendum 
question(s) for each referendum that will take 
place. It shall be protected in terms of authenticity 
and integrity. 

• Integrity 

• Authenticity 

Token data 

The TOE is activated by tokens. This means that 
tokens are presented to the TOE to enable one of 
the modes described in Table 13 and the 
corresponding functionality of the role. The TOE 
shall verify the authenticity of the token, identify 
the token and the role that is associated with this 
token and whether this role is allowed in the 
current mode. In this context, token data 
explicitly refers to data that is stored in the vote 
counter. It does not refer to any data that is stored 
on the token. 

The roles the TOE shall be able to separate are 
depicted in Table 4. 

• Integrity 

• Authenticity 

Hardware 

The hardware of the vote counter can be seen as a 
dedicated asset. The hardware shall be protected 
in terms of integrity and authenticity in order to 
allow a secure operation. 

• Integrity 

• Authenticity 

Software 

The software of the vote counter can be seen as a 
dedicated asset. The software shall be protected in 
terms of integrity and authenticity in order to 
allow a secure operation. 

• Integrity 

• Authenticity 
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Asset 

Description 

Need for Protection 

Ephemeral vote 
counter data 

The vote counter may need to work with 
ephemeral data in the course of the counting 
process. Such ephemeral data includes but is not 
limited to 

• The vote on a ballot paper that is 
currently processed 

• Intermediate counting results 

• Log file information before written to 
persistent storage 

This ephemeral data need to be protected in terms 
of integrity and need to be deleted when the 
results of an election process have been declared 
or in case a criminal investigation has been 
initiated, after that investigation has been 
completed. 

• Integrity 

Persistent 
counter data 

The vote counter counts the votes read from 
ballot papers and keeps the information on those 
read votes in memory/storage. This cumulated 
data needs to be protected in terms of integrity. 

• Integrity 

Export data 

The vote counter offers a functionality to export 
the results of the counting process. This export 
may happen as a printout and in form of an 
electronic record. The electronic record needs to 
be protected in terms of integrity and authenticity. 

• Integrity 

• Authenticity 


377 Table 5: Assets 

378 3.3 Assumptions 

379 

380 In general IT-systems, there is often a need to assume that at least a subset of the subjects that are 

381 interacting with the system can be assumed to be non-hostile. 

382 For a voting process however, such assumptions will have to be very limited. Specifically, almost 

383 everybody who gets in contact with the vote counter for making choices- either as a user or from an 

384 organisational perspective - may have a motivation, the resources and also the opportunity to 

385 manipulate (or at least attempt to manipulate) the devices. This motivation does not have to aim to 

386 actually manipulate the vote counter, but can also aim to only proof that manipulation is possible, so 

387 that the confidence in the reliability of the vote counter is reduced or dropped. 

388 lt has therefore been the clear scope in the course of the development of this chapter to put only the 

389 absolute minimum level of trust into the users of the vote counter. 

390 


Assumption 

Description 

A.Replacement 

It is assumed that a sufficiënt amount of vote counters are available in case a 
malfunction occurs and a device becomes un-operational and has to be 
replaced. 

A.SecurityF eature 

It is assumed that the ballot paper has a security feature that protects against 
forged ballot paper. This security feature will be checked by the electoral 
committee when the number of counted ballot papers is larger than the 
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Assumption 

Description 


number of admitted voters and should contribute to prevent that a ballot paper 
is counted without the feature. 

A.Expendable 

lt is assumed that any expendable material that is used by the vote counter is 
available at an adequate amount. 

A.Environment 

lt is assumed that the vote counters are operated in a controlled environment. 
Specifically, it is assumed that access to the area where voting takes place is 
controlled. During storage, configuration and transportation it is assumed that 
the ballot printer is save. lt is iurther assumed that before the voting process 
starts the feature to verify the authenticity of the ballot printer will be used 3 . 

lt is assumed that the electoral committee makes a count of the admitted 
voters and compares this to the number of votes cast in order to ensure that no 
additional votes have been counted. Further a number of random ballot papers 
are checked for proper counting. This way a significant manipulation should 
be detected. 

A.Admin 

It is assumed that the administrative roles 4 that interact with the vote counter 
have been trained with respect to their responsibilities. However it is not be 
assumed that the vote counter operators are skilled in detection of attempts of 
attacks on the vote counter or are able to detect that there is a malfïinction. 
Furthermore it is assumed, that storage and distribution of the tokens falls into 
the responsibility of an administrative role and that therefore, for the vote 
counter, it can be assumed that only persons that are allowed to have access to 
the tokens can have that access. Storage and distribution in this case refers on 
the one hand to the phase when an election is prepared and the tokens are 
distributed to the administrative roles that operate the TOE. 

A.Token 

lt is assumed that the tokens for administrative purposes are evaluated 
accordingto [PP AM], 

A.SM 

lt is assumed that the TOE has a built-in security module that provides the 
required cryptographic iunctionality and has been certified according to 
[PP_SM], 


391 Table 6: Assumptions 

392 

393 3.4 Threats 

394 The following section identifies the threats that are posed against the assets handled by the TOE. The 

395 description contains on the one hand the primary target of the attack as well as the threat agent that 

396 might conduct the attack. In this context, the term general attacker is used. The general attacker can 

397 be characterized as an attacker with high attack potential in terms of Common Criteria. He must not 

398 have the aim to actually manipulate the vote counter, but can merely aim to proof that manipulation is 

399 possible, so that the confidence in the reliability of the vote counter is reduced or dropped This means 

400 that the attacker 

401 • May spend a relevant amount of time in order to prepare/conduct an attack 

402 • Is highly skilled 


3 The assumptions regarding storage, configuration, transportation and the verification of authenticity are not 

realistic and enforceable (from a security point of view). These assumptions in the current Protection Profile 
are necessary because there are no known other physical protection mechanisms to warrant the integrity of the 
hardware of the vote counter. 

4 This basically refers to everybody interacting with the devices but the voter 
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403 

404 

405 

406 

407 

408 


Threat 

Description 

T.MultipleVotes 

An attacker could try to achieve that the vote of a voter who is in 
principle allowed to vote is counted multiple times within one counting 
process. Furthermore, the attacker could try to achieve that votes that 
have not been printed by a ballot printer are counted. These additional 
votes do not have to be the same. 

The attacker in this scenario can either be the voter who is trying to 
achieve the goal of the attack in the course of the voting process. On the 
other hand the attack can also be prepared or conducted by the vote 
counter operator or a general attacker. Also a combination of these 
attackers is possible. 

T.WrongVote 

An attacker could try to achieve that the vote of a voter is counted for a 
wrong candidate. The attacker may utilize fiinctionality of the ballot 
printer to printout a choice in a way that will cause the vote counter to 
count wrong. lt is further possible that an attacker in this scenario 
manipulates the ballot paper that has been (correctly) produced by the 
ballot printer in a way that will cause the vote counter to count wrong 
before the manipulated ballot paper is inserted into the ballot box. 

The attacker in this scenario can either be the voter who is trying to 
achieve the goal of the attack in the course of the voting process for 
themselves or for subsequent voters. On the other hand the attack can also 
be prepared or conducted by the vote counter operator who manipulates 
the ballot papers to achieve this goal or a general attacker. Also a 
combination of both attackers is possible. 

T.WrongPoll 

An attacker could try to achieve that the configuration data that the vote 
counter uses is wrong. This explicitly includes the case that the 
configuration data of the vote counter is not identical with the 
configuration data that was used by the ballot printer. This could lead to a 
situation in which a significant amount of votes are not counted as voters 
would vote for parties and candidates who are not allowed to participate 
in the election. Further, this could lead to a malfunction in counting the 
votes as the vote counter would try to recognize votes for parties and 
candidates that are actually not allowed to participate in the election. 

The attacker in this scenario can either be an administrative user who is 
trying to achieve the goal of the attack in the course of the voting process. 
On the other hand the attack can be prepared by a general attacker. Also a 
combination of these attackers is possible. 

T.WithholdVote 

An attacker could try to achieve that a cast vote is withhold. With other 
words, a vote of a voter is not counted by the vote counter. 

The attacker in this scenario can either be the voter who is trying to 
achieve the goal of the attack in the course of the printing process but for 
all subsequent voters. On the other hand the attack can also be prepared or 
conducted by the vote counter operator who manipulates the ballot papers 
to achieve this goal or a general attacker. Also a combination of these 


• Has intemal knowledge about the vote counter 

• Has access to the devices that is almost unlimited (even though the devices may not be in their 
operational mode) 

• Has access to sophisticated equipment. 
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Threat 

Description 


attackers is possible. 

T.ManipulatedCounting 

An attacker could try to manipulate the outcome of the counting of the 
votes by the vote counter. This is primarily the printed version of the 
outcome that is attached to the official report. But the attacker may also 
try to manipulate the electronic outcome of the counting or the stored 
(log) data. This attack is primarily directed against the vote counter. 

An attacker in this scenario could either be the vote counter operator or a 
general attacker. 

T.Log 

An attacker could try to gain access to the log files in order to manipulate, 
or delete them. 

The attacker in this scenario can either be the vote counter operator who 
is trying to achieve the goal of the attack in the course of the counting 
process. On the other hand the attack can also be prepared or conducted 
by a general attacker. Also a combination of both attackers is possible. 

As part of this attack, the attacker could try to modify the intemal clock. 

T.UnauthorizedAdmin 

An attacker in this scenario could try to use administrative functions that 
he is not authorized for. 

The attacker in this scenario can either be the vote counter operator who 
is trying to achieve the goal of the attack in the course of the counting 
process. On the other hand the attack can also be prepared or conducted 
by a general attacker. Also a combination of both attackers is possible. 

T.UnauthorisedUse 

An attacker in this scenario could try to use the vote counter without 
authorization. Without any form of authorization an attacker could use the 
vote counter to fmd vulnerabilities. 

The attacker in this case will be a general attacker because the authorized 
voter counter operator is allowed to use the vote counter. 

T.WrongModeChange 

An attacker in this scenario could try to manipulate the mode changes the 
vote counter is allowed to go through. The impact of this attack would be 
that the attacker has access to functionalities that should not be available 
at this point of time. 

The attacker in this scenario can either be the vote counter operator who 
is trying to achieve the goal of the attack in the course of the counting 
process. On the other hand the attack can also be prepared or conducted 
by a general attacker. Also a combination of both attackers is possible. 

T.IncorrectNumber 

An attacker could try to manipulate the vote counter in a way that the 
print of the consecutive number on the ballot paper does not correspond 
with the counting result. 

The attacker in this scenario can either be the vote counter operator who 
is trying to achieve the goal of the attack in the course of the counting 
process. On the other hand the attack can also be prepared or conducted 
by a general attacker. Also a combination of both attackers is possible. 

T.Hack 

An attacker in this scenario interacts with the vote counter , its interfaces 
or parts of it to fmd vulnerabilities and even tries to exploit 
vulnerabilities. This may compromise security and affects all assets. The 
goal of the attacker may be just to prove that there are vulnerabilities 
without compromising security or any assets and by doing so bring the 
whole voting system in discredit. 

The attacker in this scenario can either be the vote counter operator who 
is trying to achieve the goal of the attack in the course of the counting 
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Threat 

Description 


process. On the other hand the attack can also be prepared or conducted 
by a general attacker. Also a combination of both attackers is possible. 

T.SystemForgery 

An attacker in this scenario replaces the vote counter, or parts of it, with 
counterfeit parts or presents false parts as genuine vote counter parts. This 
threatens vote counter integrity, but may also result in compromise of 
assets. The goal of the attacker may be just to prove that a complete vote 
counter or parts can be replaced by non authentic ones without being 
noticed and by doing so bring the whole voting system in discredit. 

The attacker in this scenario can either be the vote counter operator who 
is trying to achieve the goal of the attack in the course of the voting 
process. On the other hand the attack can also be prepared or conducted 
by a general attacker. Also a combination of both attackers is possible. 


409 Table 7: Threats 

410 

411 3.5 Organizational Security Policies (OSPs) 

412 Organizations security policies (OSPs) are a means to require iunctionality trom a system that is 

413 considered in this Protection Pro file even though such functionality is not directly needed to mitigate 

414 an attack against the system. 

415 The following OSPs will have to be implemented by the devices in this system. 

416 


OSP 

Description 

OSP.Log 

The vote counter shall maintain a log of security relevant events. 

Those events shall include all actions with have been performed on the vote 
counter. 


417 Table 8: Organizations security policies 

418 
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419 4 Security Objectives 

420 4.1 Security Objectives for the TOE 


Objective 

Description 

O.Process 

The TOE shall ensure that it generates a reliable and correct result of the 
number of counted votes on the ballot papers. 

O.Integrity 

The TOE shall ensure the integrity of the counted data as long as it is 
remains inside the TOE. This refers to the ephemeral data that is used to 
generate the counting result as well as to the data that is pemianently 
stored in the TOE (such as the log file). 

O.Log 

The TOE shall generate audit events for each action that is performed by 
the TOE. The integrity of the audit log file shall be ensured and be 
accessible for specific roles in dedicated modes. 

O.Management 

The TOE shall provide functions to authorized roles within dedicated 
modes to manage the configuration of the TOE or to use/manage security 
features. 

• Authorized roles shall be able to upload the election data (parties 
and candidates or referendum question(s)) 

• Authorized roles shall be able to upload the token data that is 
responsible for the access control. 

• Authorized roles shall be able to delete the election data and log 
files after the central electoral committee has confirmed the 
outcome of the election or in case a criminal investigation has 
been initiated, after that investigation has been completed. 

• Authorized roles shall be able to read the audit logs. 

O.DataExchange 

The TOE shall provide an interface that allows administrative roles export 
and import of signed data. 

• The TOE shall be able to verify imported election and token data 
in terms of authenticity and integrity and only accept this data 
after verification 

• The TOE shall be able to verify software/firmware updates in 
terms of authenticity and integrity and only accept this data after 
verification 

• The TOE shall be able to sign the log file to ensure its authenticity 
and integrity after the export. 

• The TOE shall be able to sign its exported counting result to 
ensure its authenticity and integrity after the export. 

O.Selfprotection 

The TOE shall implement functions to protect itself against manipulation, 
forgery and malfunction. The vote counter shall have features to detect 
physical tampering and verify its authenticity. 

This tunctionality shall specifically protect against modification of 
hardware, software, the use of test modes or of existing back doors even if 
this does not affect security or assets. Furthermore, the manipulation of the 
power supply shall not lead to a successful attack. 

O.AccessControl 

The TOE shall control access to the TOE and to its tunctionality based on 
roles and dedicated modes as described in chapter 1.4.8. This means that 
the TOE has predefmed mode changes and within each mode only 
dedicated roles are allowed to interact with the TOE. 
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Objective 

Description 


The TOE shall authenticate a digital token that are associated with a 
dedicated role (This does not mean that the TOE gains any information 
about the user of the TOE) and check whether this token can activate the 
TOE in its current mode. 

The TOE shall ensure that it can only be activated if the role that is 
represented by the token is authorized for this mode. As part of the login 
process of roles the TOE shall - before login - present a banner message 
on the authorized use of the TOE and - after successful login of an 
administrative role - information about the last logins of that role. 


421 4.2 Security objectives for the operational environment 


Objective for 
environment 

Description 

OE.Replacement 

lt shall be ensured that a sufficiënt amount of vote counters are available in 
case a malfunction occurs and a device becomes un-operational and has to be 
replaced. 

OE.SecurityFeature 

A ballot paper that is printed by a ballot printer contains a security feature 
that protects against forged ballot paper. This security feature will be checked 
by the electoral committee when the number of counted ballot papers is 
larger than the number of admitted voters and should contribute to prevent 
that a ballot paper is counted without the feature. 

OE.Expendable 

lt shall be ensured that any expendable material that is used by the vote 
counter is available at an adequate amount. 

OE.Environment 

lt shall be ensured that the vote counter is operated in a controlled 
environment. During storage, configuration and transportation the vote 
counter should be save. Before the counting process starts the feature to 
verify the authenticity of the vote counter will be used 5 . 

Specifically, it shall be ensured that access to the area where counting takes 
place is controlled. 

The electoral committee makes a count of the admitted voters and compare 
this to the number of votes cast in order to ensure that no additional votes 
have been counted. Further a number of random ballot papers are checked 
for proper counting. This way a significant manipulation should be detected. 

OE.Admin 

lt shall be ensured that the administrative roles that interact with the vote 
counter have been trained with respect to their responsibilities. However the 
vote counter operator shall not be skilled in detection of attempts of attacks 
on the vote counter or are able to detect that there is malfunction. 

Furthermore it is assumed, that storage and distribution of the tokens falls 
into the responsibility of an administrative role and that therefore, for the 
vote counter, it can be assumed that only persons that are allowed to have 
access to the tokens can have that access. Storage and distribution in this case 
refers on the one hand to the phase when an election is prepared and the 
tokens are distributed to the administrative roles that operate the TOE. 


5 The objectives regarding storage, configuration, transportation and the verification of authenticity are not 
realistic and enforceable (from a security point of view). These objectives in the current Protection Profile are 
necessary because there are no known other physical protection mechanisms to warrant the integrity of the 
hardware of the vote counter. 
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Objective for 
environment 

Description 

OE.Token 

lt shall be ensured that the token for administrative purposes are evaluated 
according to [PP AM], 

OE.SM 

lt shall be ensured that the TOE has a built-in security module that provides 
the required cryptographic functionality and that has been certified according 
to [PP_SM], 


422 4.3 Security Objectives rationale 

423 4.3.1 OverView 

424 The following table gives an overview how the assumptions, threats, and organisational security 

425 policies are addressed by the security objectives. The text of the following sections justifies this more 

426 in detail. 
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O.Process 

O.Integrity 

O.Log 

O.Management 

O.DataExchange 

O.Selfprotection 

O.AccessControl 

OE.Replacement 

OE.SecurityFeature 

OE.Expendable 

OE.Environment 

OE.Admin 

OE.Token 

OE.SM 

T.MultipleVotes 

X 





X 





X 

X 



T.WrongVote 

X 

X 




X 









T.WrongPoll 




X 

X 

X 









T.WithholdVote 

X 





X 


X 


X 

X 




T.ManipulatedCounting 


X 



X 

X 





X 




T.Log 



X 


X 

X 

X 








T.UnauthorizedAdmin 






X 

X 





X 

X 


T.UnauthorisedUse 






X 

X 





X 



T.WrongModeChange 






X 

X 








T.Hack 






X 









T.SystemForgery 






X 





X 




T.IncorrectNumber 


X 




X 









OSP.Log 



X 



X 









A.Replacement 








X 







A.SecurityF eature 









X 






A.Expendable 










X 





A.Environment 











X 




A.Admin 












X 



A.Token 













X 


A.SM 














X 


427 Table 9: Rationale for Security Objectives 

428 4.3.2 Countering the threats 

429 The following sections provide more detailed information on how the threats are countered by the 

430 security objectives for the TOE and its operational environment. 

431 4.3.2.1 General objectives 

432 The security objectives O.Selfprotection contribute to counter each threat as it ensures the integrity of 

433 the TOE in a general sense. 

434 O.Management is needed as it defines the requirements around the management of the Security 
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435 Functions. Without a secure management no TOE can be secure. Also OE.Admin contributes to this 

436 aspect as it provides the requirements on the availability of trustworthy roles. O.Integrity requires the 

437 TOE to protect data in terms of integrity. Relevant events will be audited according O.Log that 

438 enables control whether the TOE works as specified. O.DataExchange allows import and export of 

439 required data, while its integrity and authenticity is ensured by the TOE’s digital signature. The signed 

440 export of the counting result contributes against the thread T.ManipulatedCounting after export. 

441 O.AccessControl ensures that only authorized roles are able to get access to the vote counter 

442 depending on its current mode. 

443 Those general objectives that have been argued in the previous paragraphs will not be addressed in 

444 detail in the following paragraphs. 

445 4.3.2.2 T.MultipleVotes 

446 The threat T.MultipleChoices is covered by a combination of the security objectives O.Process, 

447 O.SelfProtection, OE.Environment and OE.Admin. 

448 O.Process requires the TOE to generate a reliable and correct result of the number of counted votes on 

449 the ballot papers and therefore counters this threat. O.Selfprotection ensures that the TOE cannot be 

450 manipulated without detection to count a single scanned ballot paper more than one time. 

451 OE.Environment and OE.Admin should ensure that the operators of the TOE are trustworthy. 

452 4.3.2.3 T.WrongVote 

453 The threat T.WrongVote is covered by a combination of the security objectives O.Process, 

454 O.Integrity and O.Selfprotection. 

455 O.Process requires the TOE to generate a reliable and correct result of the number of counted votes on 

456 the ballot papers and therefore counters this threat. O.Integrity is responsible to protect the result of 

457 the counted ballot papers while they are kept in the TOE and O.Selfprotection ensures that the result 

458 of the counted ballot papers cannot be manipulated by an attack against the hardware or the software. 

459 4.3.2.4 T.WrongPoll 

460 The threat T.WrongPoll is covered by a combination of the security objectives O.Management, 

461 O.DataExchange and O.Selfprotection. 

462 O.Selfprotection ensures that the election data cannot be manipulated by unauthorised users without 

463 detection. O.Management restricts the access to the management functionality of the TOE and the 

464 token that actives the functionality to configure the election data to authorized persons. 

465 O.DataExchange ensures that only data with verifiable integrity and authenticity can be imported into 

466 the TOE. 

467 4.3.2.5 T.WithholdVote 

468 The threat T.WithholdVote is covered by a combination of the security objectives O.Process, 

469 O.Selfprotection, OE.Replacement, OE.Expendable and OE.Environment. 

470 O.Process and OE.Environment should ensure that ballot papers will be scanned. Further, in 

471 OE.Environment it is defined that the Electoral Committee compares the total number of votes cast 

472 with the number of admitted voters. O.Selfprotection ensures that the TOE cannot be manipulated 

473 without detection to withhold votes. OE.Replacement and OE.Expendable ensure that spare vote 

474 counters as well as used materials are available at an adequate amount for the case that the vote 

475 counter becomes un-operational or the vote counter runs out of material like ink or papers . 

476 4.3.2.6 T.ManipulatedCounting 

477 The threat T.ManipulatedCounting is covered by a combination of the security objectives 

478 O.Integrity, O.Selfprotection, O.DataExchange and OE.Environment. 

479 O.Integrity and O.Selfprotection ensure that the TOE cannot be manipulated without detection in a 

480 way that the counting results are manipulated. O.DataExchange ensures that the TSF data that is used 
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481 in the context of counting is transmitted in a protected mannen Further, in OE.Environment it is 

482 defmed that the Electoral Committee compares the total number of votes cast with the number of 

483 admitted voters. 

484 4.3.2.7 T.Log 

485 The threat T.Log is covered by a combination of the security objectives O.Log, O.DataExchange, 

486 O.Selfprotection and O.AccessControl. 

487 O.Selfprotection ensures that the log in the vote counter cannot be manipulated without detection. 

488 O.Log and O.AccessControl ensure that only authorized roles have access to the log and that every 

489 action is recorded with integrity. O.DataExchange requires that exported audit records must be signed 

490 to ensure its integrity and authenticity. 

491 4.3.2.8 T.UnauthorizedAdmin 

492 The threat T.UnauthorizedAdmin is covered by a combination of the security objectives 

493 O.Selfprotection O.AccessControl, OE.Admin and OE.Token. 

494 O.Selfprotection ensures that the vote counter cannot be manipulated without detection to use 

495 administrative functionalities outside the specification. O.AccessControl and OE.Admin ensure that 

496 users can only gain access to the functionalities that they are allowed to use. OE.Token requires the 

497 use of tokens that have been evaluated in accordance with [PP-AM] and must therefore ensure a high 

498 security against manipulation. 

499 4.3.2.9 T.UnauthorisedUse 

500 The threat T.UnauthorizedUsed is covered by a combination of the security objectives 

501 O.Selfprotection O.AccessControl and OE.Admin. 

502 O.Selfprotection ensures that the vote counter cannot be manipulated without detection to enable the 

503 counting by persons without a token. O.AccessControl and OE.Admin ensure that a user only gains 

504 access with the token to the functionalities they are allowed to use in a specific mode of the TOE. 

505 4.3.2.10 T.WrongModeChange 

506 The threat T.WrongModeChange is covered by a combination of the security objectives 

507 O.Selfprotection and O.AccessControl. 

508 O.Selfprotection ensures that the vote counter cannot be manipulated without detection to make a 

509 mode change that is not allowed and gain access to functionalities that should not be available. 

510 O.AccessControl enforces that only persons that are represented by dedicated token can change the 

511 mode of the TOE and have no access to modes that should not be available. 

512 4.3.2.11 T.Hack 

513 The threat T.Hack is covered by the security objective O.Selfprotection. 

514 O.Selfprotection ensures that the vote counter is protected against vulnerabilities to 

515 compromise or exploit a vote counter. 

516 4.3.2.12 T.SystemEorgery 

517 The threat T.System_forgery is covered by the security objectives O.Selfprotection and 

518 OE.Environment. 

519 O.Selfprotection ensures that parts of the vote counter cannot be manipulated without a 

520 detection. The feature to verify authenticity makes it possible to detect a non authentic vote 

52 1 counter. OE.Environment ensures that the feature to verify the authenticity of the vote 

522 counter is used before the counting process starts. 

523 4.3.2.13 T.IncorrectNumber 

524 The threat T.IncorrectNumber is covered by a combination of the security objectives OTntegrity 

525 and O.Selfprotection. 
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526 O.Integrity and O.Selfprotection ensure that the consecutive number printed on the ballot papers 

527 cannot be manipulated while the ballot papers are processed within the TOE. 

528 4.3.3 Coverage of organisational security policies 

529 The following sections provide more detailed information about how the security objectives for the 

530 environment and the TOE cover the organizational security policies. 

531 4.3.3.1 OSP.Log 

532 The Organisational Security Policy OSP.Log that mandates that the TOE maintains an audit log is 

533 directly addressed by the security objective for the TOE O.Log 

534 4.3.1 Coverage of assumptions 

535 The following sections provide more detailed information about how the security objectives for the 

536 environment cover the assumptions. 

537 4.3.1.1 A.Replacement 

538 The assumption A.Replacement is directly and completely covered by the security objective 

539 OE.Replacement. The assumption and the objective for the environment are drafted in a way that the 

540 correspondence is obvious. 

541 4.3.1.2 A.SecurityFeature 

542 The assumption A.SecurityFeature is covered by the security objective OE.SecurityFeature. The 

543 assumption and the objective for the environment are drafted in a way that the correspondence is 

544 obvious. 

545 4.3.1.3 A.Expendable 

546 The assumption A.Expandable is directly and completely covered by the security objective 

547 OE.Expandable. The assumption and the objective for the environment are drafted in a way that the 

548 correspondence is obvious. 

549 4.3.1.4 A.Environment 

550 The assumption A.Environment is directly and completely covered by the security objective 

551 OE.Environment. The assumption and the objective for the environment are drafted in a way that the 

552 correspondence is obvious. 

553 4.3.1.5 A.Admin 

554 The assumption A.Admin is directly and completely covered by the security objective OE.Admin. 

555 The assumption and the objective for the environment are drafted in a way that the correspondence is 

556 obvious. 

557 4.3.1.6 A.Token 

558 The assumption A.Token is directly and completely covered by the security objective OE.Token. The 

559 assumption and the objective for the environment are drafted in a way that the correspondence is 

560 obvious. 

561 4.3.1.7 A.SM 

562 The assumption A.SM is directly and completely covered by the security objective OE.SM. The 

563 assumption and the objective for the environment are drafted in a way that the correspondence is 

564 obvious. 
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565 5 Extended Component definition 


566 5.1 Definition of the Family ALC DEL.2 

567 Objectives 

568 The concern of this family is the secure transfer of the fmished TOE ffom the development 

569 environment into the responsibility of the user. 

570 The requirements for delivery call for system control and distribution facilities and procedures that 

571 detail the measures necessary to provide assurance that the security of the TOE is maintained during 

572 distribution of the TOE to the user. For a valid distribution of the TOE, the procedures used for the 

573 distribution of the TOE address the objectives identified in the PP/ST relating to the security of the 

574 TOE during delivery. 

575 The extension of this family shall ensure the qualification of every single vote counter. This 

576 means that every device shall be investigated after its production whether it corresponds to the 

577 evaluated version of the TOE. The investigation shall ensure, that the developer has not changed 

578 or modified any component. 

579 Component levelling 


580 

581 

582 

583 

584 

585 

586 

587 

588 

589 

590 

591 

592 

593 

594 

595 

596 

597 

598 

599 

600 
601 

602 

603 


ALC_DEL: Delivery - 1 - 2 

This family contains two components. An increasing level of protection is established by requiring 
commensurability of the delivery procedures with the assumed attack potential in the family 
Vulnerability analysis (AVA_VAN). 

Application notes 

Transportations from subcontractors to the developer or between different development sites are not 
considered here, but in the family Development security (ALC DVS). 

The end of the delivery phase is marked by the transfer of the TOE into the responsibility of the user. 
This does not necessarily coincide with the arrival of the TOE at the user's location. 

The delivery procedures should consider, if applicable, issues such as: 

a) ensuring that the TOE received by the consumer corresponds precisely to the evaluated 
version of the TOE; 

b) avoiding or detecting any tampering with the actual version of the TOE; 

c) preventing submission of a false version of the TOE; 

d) avoiding unwanted knowledge of distribution of the TOE to the consumer: there might be 
cases where potential attackers should not know when and how it is delivered; 

e) avoiding or detecting the TOE being intercepted during delivery; and 

f) avoiding the TOE being delayed or stopped during distribution. 


The delivery procedures should include the recipient's actions implied by these issues. The consistent 
description of these implied actions is examined in the Preparative procedures (AGD PRE) family, if 
present. 

The description of ALC_DEL.2 refers to the terms “user” and “consumer”. Within this document, 
these terms are synonym to the governmental agency that receives the produced vote counters. It has 
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604 been balanced whether it was better to develop a new assurance component or to use a known 

605 component and augment it. The latter has been chosen due to the assumption, that it is more suitable 

606 for evaluation if dedicated components base on the existing structure of classes and families. 

607 ALCDEL.2 Delivery procedures 

Dependencies: No dependencies. 

Developer action elements: 

ALCDEL.2.1D The developer shall document and provide procedures for delivery of the 

TOE or parts of it to the consumer. 


ALCDEL.2.2D The developer shall use the delivery procedures. 

ALCDEL.2.3D The developer shall document and provide evidence that every single 

vote counter corresponds precisely to the evaluated version of the TOE. 


Content and presentation elements: 


ALC DEL.2.1C The delivery documentation shall describe all procedures that are necessary 

to maintain security when distributing versions of the TOE to the consumer. 

Evaluator action elements: 


ALCDEL.1.1E 

ALC DEL.1.2E 


608 


The evaluator shall confirm that the information provided meets all 
requirements for content and presentation of evidence. 

The evaluator shall confirm for every single vote counter that it 
corresponds precisely to the evaluated version of the TOE. 


609 5.2 Deflnition of the Family FDPFPC.l 

610 Objectives 

611 The concern of the family FDPFPC (Functional Process Controls) is the insurance that functional 

612 processes performed by the TOE operate exactly as defined in dedicated rules and policies. 

613 The family “Functional Process Controls” (FDP FPC) is specified as follows 

614 Family behaviour: 

615 This family defines the functional processes the TOE has to provide. 

616 Component levelling: 

Management: FDPFPC.l 

There are no management activities foreseen. 

Audit: The following actions should be auditable if FAU GEN Security audit 

data generation is included in the PP/ST: 
a) Basic: Violation of rules or policies 

617 FDP FPC.1 Functional Process Controls 

The TSF shall enforce the [ assignment: process policy ] for the following 
[assignment: list of subjects, information , objects, processes], 

The TSF shall enforce the following rules [assignment: process rules]. 

No other components 
No other components 


FDPFPC.l.l 

FDPFPC.1.2 

Hierarchical to: 
Dependencies: 
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618 6 Security Requirements 


619 

620 
621 
622 

623 

624 

625 

626 

627 

628 

629 

630 

631 

632 

633 

634 

635 


6.1 OverView 

This chapter describes the security functional and the assurance requirements which have to be 
fulfilled by the TOE. Those requirements comprise functional components from part 2 of [CC] and the 
assurance components as defined for the Evaluation Assurance Level 4 ff om part 3 of [CC]. 

The following notations are used: 

• Refinement operation (denoted by bold text): is used to add details to a requirement, and thus 
further restricts a requirement. In case that a word has been deleted from the original text this 
refinement is indicated by cross e d out bold text 

• Selection operation (denoted by underlined text) : is used to select one or more options 
provided by the [CC] in stating a requirement. 

• Assignment operation (denoted by italicised text): is used to assign a specific value to an 
unspecified parameter, such as the length of a password. 

• Iteration operation: are identified with a suffix in the name of the SFR (e.g. 
FMT MOF.l/Mode). 


lt should be noted that the requirements in the following chapters are not necessarily be ordered 
alphabetically. Where useful the requirements have been grouped. 

The following table summarises all TOE security functional requirements of this PP: 


Class FAU: Security Audit 

FAUARP.l 

Security alarms 

FAUGEN.l 

Audit data generation 

FAUGEN.2 

User identity association 

FAU_S AA. 1 

Potential violation analysis 

FAUSTG.1 

Protected audit trail storage 

FAUSTG.4 

Prevention of audit data loss 

Class FCS: Cryptographic Support 

FCSCOP.l 

Cryptographic operation 

Class FDP: User Data Protection 

FDPACC.2 

Complete access control 

FDPACF.l 

Security attribute based access control 

FDPDAU.l 

Basic Data Authentication 

FDPFPC.l 

Functional Process Controls 

FDP1FC.2 

Complete information flow control 

FDPIFF.1 

Simple security attributes 

FDP1TT.2 

Transmission separation by attribute 

FDP1TT.4 

Attribute-based integrity monitoring 
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FDPSDI.2 

Stored data integrity monitoring and action 

Class FIA: Identification and Authentication 

FIAAFL. 1 

Authentication failure handling 

FIAATD.l 

User attribute defmition 

FIA_UAU.2 

User authentication before any action 

FIAUID.2 

User identification before any action 

FIAUSB.l 

User-subject binding 

Class FMT: Security Management 

FMTMTD.l 

Management of TSF data 

FMTMOF.l 

Management of security functions behaviour 

FMTMOF. 1 /Mode 

Management of security functions behaviour for the mode 

FMT_MSA.3 

Static attribute initialisation 

FMT_MSA. 1 

Management of security attributes 

FMT_MSA.2 

Secure security attributes 

FMTSMR.l 

Security roles 

FMTSMF. 1 

Specification of Management Functions 

Class FPT: Protection of the TSF 

FPTPHP.2 

Notification of physical attack 

FPTPHP.3 

Resistance to physical attack 

FPTRCV.3 

Automated recovery without undue loss 

FPTRCV.4 

Function recovery 

FPTTST.l 

TSF testing 

FPTITI. 1 

Inter-TSF detection of modification 

FPTRPL.l 

Replay detection 

FPTFLS.l 

Failure with preservation of secure state 

FPTSTM. 1 

Reliable time stamps 

Class FRU: Resource utilisation 

FRUFLT.2 

Limited fault tolerance 

Class FTA: TOE access 

FTASSL.3 

TSF-initiated termination 

FTASSL.4 

User-initiated termination 

FTATAB.l 

Default TOE access banners 
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FTA:TAH.1 

TOE access history 

FTATSE.l 

TOE session establishment 


636 Table 10: List of Security Functional Requirements 

637 6.2 Class FAU: Security Audit 

638 6.2.1.1 Security audit automatic response (FAUARP) 

639 6.2.1.1.1 FAUARP.l: Security alarms 

FAUARP.l.l The TSF shall take [ notify the user and enter the mode “ management ”] 

upon detection of a potential security violation. 

Hierarchical to: No other components 

Dependencies: FAUSAA.l 

640 6.2.1.2 Security audit data generation (FAU GEN) 

641 6.2.1.2.1 FAU GEN.l: Audit data generation for system log 

FAU GEN. 1.1 The TSF shall be able to generate an audit record of the following auditable 

events: 

a) Start-up and shutdown of the audit functions; 

b) All auditable events for the [detailedl level of audit; and 

c) [additional audit events for all actions performed by the TOE as 
specified in Table 11, 

d) [assignment: further actions or none]] 

FAU GEN.1.2 The TSF shall record within each audit record at least the following 

information: 

a) Date and time of the event, type of event, subject identity (if 
applicable), and the outcome (success or failure) of the event; and 

b) For each audit event type, based on the auditable event defmitions 
of the functional components included in the PP/ST, [assignment: 
other audit relevant information], 

Hierarchical to: No other components 

Dependencies: FPTSTM. 1 

Application Note: The following table lists relevant events for the level of audit “detailed” 

structured after all used SFRs. 

642 

643 
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644 

645 


SFR 

Audited events 

FAUARP.l 

Actions taken due to potential security violations. 

FAUGEN.l 

- 

FAUGEN.2 

- 

FAU_S AA. 1 

Enabling and disabling of any of the analysis mechanisms; 

Automated responses performed by the tooi. 

FAUSTG.1 

Actions taken due to exceeding of a threshold. 

FAUSTG.4 

Actions taken due to the audit storage failure. 

FCSCOP.l 

Any applicable cryptographic mode(s) of operation, subject attributes and 
object attributes. 

FDPACC.2 

- 

FDPACF.l 

The specific security attributes used in making an access check. 

FDPDAU. 1 

The identity of the subject that requested the evidence. 

FDPFPC.l 

Violation of rules or policies 

FDPIFC.2 

- 

FDPIFF.l 

- 

FDPITT.2 

All attempts to transfer user data, including the protection 
method used and any errors that occurred. 

FDPITT.4 

The action taken upon detection of an integrity error. 

FDPSDL2 

The type of integrity error that occurred. 

The action taken upon detection of an integrity error. 

FIAAFL.l 

The reaching of the threshold for the unsuccessful authentication attempts and 


the actions (e.g. disabling of a terminal) taken and the subsequent, if 
appropriate, restoration to the normal state (e.g. re-enabling of a terminal). 

FIAUAU.2 

All use of the authentication mechanism. 

FIAUSB.l 

Success and failure of binding of user security attributes to a subject (e.g. 
success or failure to create a subject). 

FIAATD.l 

- 

FIAUID.2 

All use of the user identification mechanism, including the user identity 


provided. 

FMTMTD.l 

All modifications to the values of TSF data. 

FMTMOF.l 

All modifications in the behaviour of the functions in the TSF. 

FMT_MOF. 1 /Mode 

All modifications in the behaviour of the functions in the TSF. 
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646 


SFR 

Audited events 

FMTMSA.3 

Modifications of the default setting of permissive or restrictive rules. 

All modifications of the initial values of security attributes. 

FMT_MSA. 1 

All modifications of the values of security attributes. 

FMT_MSA.2 

All offered and rejected values for a security attribute; 

All offered and accepted secure values for a security attribute. 

FMT_SMR. 1 

Every use of the rights of a role. 

FMT_SMF. 1 

Use of the management functions. 

FPTPHP.2 

Detection of intrusion. 

FPTPHP.3 

- 

FPTTST.l 

Execution of the TSF self tests and the results of the tests. 

FPTRCV.3 

Type of failure or service discontinuity 

FPTRCV.4 

lf possible, the detection of a failure of a function. 

FPTITLl 

Detected modification of TSF data during transmission and action taken. 

FPTRPL.l 

Action to be taken based on the specific actions. 

FPTFLS.l 

Failure of the TSF. 

FPTSTM.l 

Providing a timestamp. 

FRUFLT.2 

Any failure detected by the TSF. 

FTASSL.3 

Termination of an interactive session by the session locking mechanism. 

FTA_SSL.4 

Termination of an interactive session by the user. 

FTATAB.l 

- 

FTATAH.l 

- 

FTATSE.l 

Capture of the value of the selected access parameters (e.g. location of access, 
time of access). 


Table 11: Audit events 


Event 

Additional information 

Update software/firmware code 

Token 1D 

Perform selftest 

Token 1D 

Import of election configuration data 

Token 1D 

Test vote counter function 

Token 1D 

Export of the log file 

Token 1D 

Export of counting result 

Token 1D 

Erase of counting results, configuration data and 
log 

Token 1D 
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Event 

Additional information 

Import of token data 

Token 1D 

Import of key store configuration data 

Token 1D 

Enter number of polling station or ballot box 
number 

Token 1D 

Export election configuration data 

Token ID 

Export token data 

Token ID 

Export firmware/software 

Token ID 

Activation with token 

Token ID 

Change of mode 

Token ID 

Count ballots 

Token ID 

Print counting result 

Token ID 

Recognised Vote 

Token ID 

Error that has occurred, like out of paper, paper 
jam, wrong token for current mode, not-authentic 
token used 

Token ID 


647 Table 12: Additional Audit events 

648 6.2.1.2.2 FAU GEN.2: Audit data generation for system log 

FAUGEN.2.1 For audit events resulting trom actions of identified users, the TSF shall be 

able to associate each auditable event with the identity of the user 
that caused the event. 

Ilicrarchical to: No other components 


Dependencies: FAUGEN.l 

FIAUID.1 

Application Note: lt should be noted that the system of authentication of the TOE bases on 

tokens. Those tokens are treated as users even though the TOE will never 
get hold of the real user identity. Whenever the identity of the user is 
mentioned in the context of an SFR, this therefore refers to the 1D of the 
token. 

649 

650 6.2.1.2.3 FAU SAA.1 Potential violation analysis 

FAUSAA.l.l The TSF shall be able to apply a set of rules in monitoring the audited 

events and based upon these rules indicate a potential violation of the 
enforcement of the SFRs. 


FAU SAA. 1.2 The TSF shall enforce the following rules for monitoring audited events: 

a. Accumulation or combination of [assignment: subset of 
defined auditable events] known to indicate a potential security 
violation; 

b. [assignment: any other rules], 

Hierarchical to: No other components 


Bijlage: Protection Profile stemmenteller 


42 




Vote Counter-PP 


Dependencies: FAUGEN.l 

Application Note: The accumulation of events that has to be filled into the assignment in 

FAU SAA. 1.2 strongly depends on the concrete implementation of the 
TOE. lt is therefore left open to the specification and ST author. 

65 1 6.2.1.3 Security audit event storage (FAUSTG) 

652 6.2.1.3.1 FAUSTGl Protected audit trail storage 

FAU STG. 1.1 The TSF shall protect the stored audit records in the audit trail ffom 

unauthorised deletion. 

FAU STG. 1.2 The TSF shall be able to [prevent! unauthorised modifications to the stored 

audit records in the audit trail. 

Hierarchical to: No other components 

Dependencies: FAUGEN. 1 

653 6.2.1.3.2 FAU STG4: Prevention of audit data loss 

FAU STG.4.1 The TSF shall rignore audited events! and [switch into the mode 

“management ”] if the audit trail is full. 

Hierarchical to: FAU STG.3 

Dependencies: FAUSTGl 

Application Note: Before the audit trail is full the TOE must give warnings. 

654 

655 

656 6.3 Class FCS: Cryptographic Operation 

657 6.3.1.1.1 FCSCOP.l Cryptographic operation 

FDP COP.l.l The TSF shall perform [hashing, signature verification ] in accordance with 

a specified cryptographic algorithm [ assignment: cryptographic algorithm\ 
and cryptographic key sizes [assignment: cryptographic key sizes ] that 
meet the following: [assignment: list of standards], 

Hierarchical to: No other components. 

Dependencies: FDP IFF.1 Simple security attributes 

658 

659 6.4 Class FDP: User data protection 

660 6.4.1.1 Access control policy (FDP ACC) 

661 6.4.1.1.1 FDP ACC.2: Complete access control 

FDPACC.2.1 The TSF shall enforce the [vote counter access SFP ] on [ 
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Subjects: 

• all users 

• [assignment: list offurther subjects, ornonej. 

Objects: 

• vote, 

• persistent and ephemeral vote counter data, 

• all TSF data, 

• [assignment: list of further objects, or none]. 

] and all operations among subjects and objects covered by the SFP. 

FDPACC.2.2 The TSF shall ensure that all operations between any subject controlled by 

the TSF and any object controlled by the TSF are covered by an access 
control SFP. 

Flierarchical to: FDPACC.l 

Dependencies: FDPACF.l 

Application Note: The SFR FDPACC.2 introducés the access control policy for the TOE. A 

more tunctional overview over this can be found in chapter 1.4.8 

The TOE refers to the current mode of operation and the role of the current 
user for access control. In so far the access control fimctionality can be 
seen as a special form of a Role Based Access Control. 

More details on the rules that are used for access control can be found in 
FDPACF.l. 

662 6.4.1.2 Access control functions (FDPACF) 

663 6.4.1.2.1 FDP ACF.l: Security attribute based access control 

FDP ACF. 1.1 The TSF shall enforce the [ vote counter access SFP] to objects 

based on the following: [ 

Security attributes for subjects: 

• Authenticated role of current user (ROLEID), 

• Current mode (MODEID) 

• [assignment: additional security attributes for subjects, or none] 
Security attributes for objects: 

• [assignment: additional security attributes for objects, or none] 

]• 

FDP ACF. 1.2 The TSF shall enforce the following rules to determine if an operation 

among controlled subjects and controlled objects is allowed: [ 

An operation between a subject and an object shall be allowed if 

A) the ROLE ID has the permission to perform this operation (as 
depicted in Table 13) AND 

B) The operation is permitted within the current mode (MODE ID) 
(as depicted in Table 13) 

Else 


Bijlage: Protection Profile stemmenteller 


44 



Vote Counter-PP 


FDPACF.1.3 

FDP ACF.1.4 


Flierarchical to: 


The operation is prohibited 

]• 

The TSF shall explicitly authorise access of subjects to objects based on the 
following additional rules: [none]. 

The TSF shall explicitly deny access of subjects to objects based on the 
following additional rules: [none]. 

No other components 


Dependencies: FDPACC. 1 

FMT_MSA.3 

Application Note: FDPACF.l defines the access control policy for the TOE. As outlined in 

chapter 1.4.8 it bases on the role of the current user and the current mode of 
the TOE. 

The access control policy rules as defined in FDP ACF. 1.2 ensure that an 
operation is only allowed if the role has the permission and the 
functionality is available in the current mode. 

By using “none” in the assignments in FDP ACF.1.3 and FDP ACF.1.4 it 
is ensured that the ST author cannot define additional rules that would 
overrule this access control policy. 


664 


TOE mode 

Role (ROLE ID) 

Allowed Operations 

Possible 

mode(s) 6 

next 

MANAGEMENT 


Import election 
configuration data 

Test vote counter 
function 




Update software/ 
firmware code 




Import Token data 

Import key store 
configuration data 




Enter number of 
polling station or ballot 
box number 



(de)Configurator 

Export log 

Export election 
configuration data 

Export token data 

Export counting result 
Export 

firmware/software 



6 A mode is identified by its MODE1D 
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Erase counting data, 
configuration data and 
log 




Shutting down system 

- 



Change mode, 

only possible if 
configuration data is 
complete, tokens have 
been assigned to 
elections and number 
of polling station or 
ballot box has been 
entered 

ELECTION 


Vote Counter Operator 

Shutting down system 

- 

ELECTION 

(de)Configurator 

None 

_ 



Enter / verify number 
of polling station or 
ballot box number 

Perform selftest 




Count ballots 

Print counting result 

_ 



Export counting result 



Vote Counter Operator 

Shutting down system 

MANAGEMENT 



Detection of a possible 
manipulation or a 
defect 

MANAGEMENT 


665 Table 13: TOE modes and subjects allowed interaction in the mode 

666 6.4.1.3 Data authentication (FDPDAU) 

667 6.4.1.3.1 FDP DAU.l: Basic Data Authentication 

FDPDAU. 1.1 

FDPDAU. 1.2 

Hierarchical to: 

Dependencies: 

Application Note: 


The TSF shall provide a capability to generate evidence that can be used as 
a guarantee of the validity of [the log and counting result]. 

The TSF shall provide [the (de)configurator] with the ability to verify 
evidence of the validity of the indicated information. 

No other components 
No dependencies 

FDP DAU. 1 is present in this PP to make sure that the log file and 
counting result that can be exported from the TOE is authentic and integer. 
Such functionality can e.g. be implemented by the use of a digital 
signature. Such a signature would then allow the reviewer to verify that the 
log file is authentic and integer. 
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668 6.4.1.4 Functional Process Controls (FDPFPC) 

669 6.4.1.4.1 FDP FPC.l Functional Process Controls 

FDP FPC 1 1 

- ' ' The TSF shall enforce the [assignment: process policy ] for the following 

[assignment: list of subjects, information, objects, pmcesses]. 


FDP FPC. 1.2 


The TSF shall enforce the following mies [assignment: process rules ]. 


Flierarchical to: No other components 

Dependencies: No other components 


Application Note: This TSF models the concrete mies that model the counting functionality of 

the TOE. This needs to be in the PP to have security objective O.Process 
covered. The concrete assignments in FDP FPC. 1 are left open to the ST 
author. The ST author shall consider the corresponding functional 
specification for the vote counter when completing the assignments in 
FDP FPC.1. 


670 6.4.1.5 Information flow control policy (FDP1FC) 

671 6.4.1.5.1 FDP 1FC.2 Subset information flow control 


FDP1FC.2.1 The TSF shall enforce the [interna! information flow control SFP ] on [ 

Subjects: TOE modules 
Information (assets): 

• logs, 

• token data , 

• configuration data, 

• votes, 

• counting data , 

• ephemeral vote counter data , 

Operations: any 

] and all operations that cause that information to flow to and from subjects 
covered by the SFP. 


FDP 1FC 2 2 The TSF shall ensure that all operations that cause any information in the 

TOE to flow to and from any subject in the TOE are covered by an 
information flow control SFP. 


Flierarchical to: 


FDP IFC.1 


Dependencies: 


FDP1FF. 1 Simple security attributes 
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672 6.4.1.6 Information flow control functions (FDPIFF) 

673 6.4.1.6.1 FDP IFF.1 Simple security attributes 

FDPIFF. 1.1 The TSF shall enforce the [internal information flow control SFP] based on 

the following types of subject and information security attributes: [subjects 
and information according to FDPIFC.2.1 and the following security 
attribute: 

• necessity to transfer the asset to other TOE modules 

l 

FDPIFF.1.2 The TSF shall permit an information flow between a controlled subject and 

controlled information via a controlled operation if the following rules 
hold: [ 

Any information listed in FDP IFC.2.1 shall only be transferred between 
those TOE modules that actually need to process the information to fulfill 
their purpose according to the design of the TOE. If at any time such 
information is part of a larger set of information, TOE modules shall make 
sure to decompose the larger set and only transfer the necessary 
information to other TOE modules. 

I 


FDP 1FF.1.3 


The TSF shall enforce the [no further rules]. 


FDP 1FF.1.4 


The TSF shall explicitly authorise an information flow based on the 
following rules: [none]. 


FDP 1FF.1.5 


The TSF shall explicitly deny an information flow based on the following 
rules: [none]. 


Hierarchical to: 


No other components. 


Dependencies: FDPIFC.l Subset information flow control 

FMT_MSA.3 Static attribut e initialisation 

Application Note: FDPIFC.2 and FDPIFF. 1 are used to express the requirement that the 

TOE assets shall not be available to all parts of the TOE but only to those 
parts that make use of it. The restriction on information flow defined in 
FDPIFF.1.2 will ensure that. FDPIFF.1.3, FDPIFF.1.4 and FDPIFF.1.5 
are not used because there are no further rules necessary to express the 
requirement. In this case, according to [CC Part 2, chapter F. 6], the PP/ST 
author should specify “none”. 

Since the security attribute necessity to transfer the asset to other TOE 
modules is determined during development for each asset and is not 
configurable, the dependency FMT MSA.3 of FDP IFF. 1 is not necessary. 

TOE modules and their interactions will be described in detail by the 
developer to fulfïl the requirements of ADV TDS.5. Therefore, the 
evaluator has all means to verify the correct implementation of this SFP. 

During evaluation of aspect ADV INT.3 the evaluator will also analyze 
whether the modular design of the TOE is well-structured. A well- 
structured modular design supports that sensitive information is only 
present where necessary. 
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674 6.4.1.7 Internal TOE transfer (FDPITT) 

675 6.4.1.7.1 FDP ITT.2 Transmission separation by attribute 


676 


677 

678 

679 


FDPITT.2.1 

The TSF shall enforce the [vote counter access SFP or internal 
Information flow control SFP 1 to prevent the Tmodification and loss of 
usel of user data when it is transmitted between physically-separated 
parts of the TOE. 

FDP1TT.2.2 

The TSF shall separate data controlled by the SFP(s) when transmitted 
between physically-separated parts of the TOE, based on the values of the 
following: [assignment: security attributes that require separation]. 

Hierarchical to: 

FDPITT. 1 

Dependencies: 

[FDP ACC. 1 Subset access control, or FDP IFC.1 Subset information 
flow control] 

6.4.1.7.2 FDPITT.4 Attribute-based integrity monitoring 

FDPITT.4.1 

The TSF shall enforce the [ vote counter access SFP or internal information 
flow control SFP ] to monitor user data transmitted between physically- 
separated parts of the TOE for the following errors: [assignment: integrity 
errors], based on the following attributes: [assignment: security attributes 
that require separate transmission channels]. 

FDPITT.4.2 

Upon detection of a data integrity error, the TSF shall [assignment: specify 
the action to be taken upon integrity error]. 

Hierarchical to: 

FDPITT.3 

Dependencies: 

[FDP ACC. 1 Subset access control, or FDP IFC.1 Subset information 
flow control] FDP ITT.2 Transmission separation by attribute 

Application Note: 

It should be noted that the requirements FDP ITT.2 and FDP ITT.4 are 
dedicated to cases in which the TOE comprises physically separated parts. 
In cases, where the TOE does not comprise physically separated parts, 
those requirements shall be considered being fulfilled without any 
implementation/evidence. 

6.4.1.8 Stored data integrity (FDPSDl) 

6.4.1.8.1 FDP SDI.2 Stored data integrity monitoring and action 

FDPSDI.2.1 

The TSF shall monitor user data stored in containers controlled by the TSF 
for [ integrity errors] on all objects, based on the following attributes: 
[assignment: attributes defined by the ST author]. 

FDPSDI.2.2 

Upon detection of a data integrity error, the TSF shall [switch into the mode 
“management”]. 

Hierarchical to: 

FDPSDl. 1 

Dependencies: 

No dependencies 

Application Note: 

The user data controlled by the TSF (votes, counting data, ephemeral data) 
must have attributes that enable the TOE to monitor the integrity of this 
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data. The attribute may be a suitable hash value or any other suitable 
attribute that matches the specification and has to be specified by the ST 
author in the ST in the last assignment in FDPSDI.2.1. 


680 6.5 Class FIA: Identification and Authentication 

Application Note: The concept to operate the TOE is based on a procedure that activates the 

TOE for a specific purpose. This activation uses digital token that are 
presented to the TOE and are dedicated to a specific role (see Table 13) 
with a limited fiinctionality and only in dedicated modes. More precisely: 
Every role has a specific token and is only able to activate the TOE for their 
specific purpose if the TOE is in a mode where this role is allowed to 
interact with the TOE. For more details on the access control policy behind 
this concept please refer to chapter 1.4.8. 

Please note that even though the SFRs within this chapter refer to a “user” 
this does not mean that the identity of the user has to be known by the 
TOE. 

681 

682 6.5.1.1 Authentication failures (F1A AFL) 

683 6.5.1.1.1 FIA AFL.l Authentication failure handling 

The TSF shall detect when [selection: [assignment: positive integer 
number ], an administrator configurable positive integer within 
[assignment: range of acceptable values ]] unsuccessful authentication 
attempts occur related to [assignment: list of authentication events ]. 

When the defined number of unsuccessful authentication attempts has been 
[selection: met, surpassed], the TSF shall [assignment: list of actions], 

No other components. 

FlA UAU.l Timing of authentication 

F1A AFL. 1 is used in this PP to ensure that the authentication functionality 
is resistant against brute force attacks. lt is in the intention of the authors of 
this PP that the mechanism behind it shall only block the authentication 
function of the TOE for a certain amount of time after a certain number of 
unsuccessful attempts occurred. This way is can be ensured that this 
function cannot be misused to attack the availability of the TOE. However, 
the concrete assignments in FIA AFL.l are left to the specification and ST 
author as they highly depend on implementation details (such as the speed 
of the authentication function) 

684 6.5.1.2 Token attribute definition (F1A ATD) 

685 6.5.1.2.1 FIA ATD.l User attribute definition 

FlA ATD.l.l The TSF shall maintain the following list of security attributes belonging 

to individual users: [role-id, token-id [assignment: additional security 
attributes, or none]]. 

Hierarchical to: No other components. 

Dependencies: No dependencies. 


FlAAFL.l.l 

F1AAFL.1.2 

Hierarchical to: 
Dependencies: 
Application Note: 
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686 6.5.1.3 User identification (FIA UID) 

687 6.5.1.3.1 FIAUID.2 User identification before any action 



FIAUID.2.1 

The TSF shall require each user to be successfïilly identified before 
allowing any other TSF-mediated actions on behalf of that user. 


Hierarchical to: 

FIAUID.1 


Dependencies: 

No dependencies 

688 

6.5.1.4 User authentication (F1A UAU) 

689 

6.5.1.4.1 FIA 

UAU.2 User authentication before any action 


FIAJJAU.2.1 

The TSF shall require each user to be successfully authenticated before 
allowing any other TSF-mediated actions on behalf of that user. 


Hierarchical to: 

FlAUAU.l 


Dependencies: 

FIAUID.1 

690 

6.5.1.5 User-subject binding (FIA USB) 

691 

6.5.1.5.1 FIA 

USB.1 User-subject binding 


FIAUSB.l.l 

The TSF shall associate the following user security attributes with 
subjects acting on the behalf of that user: [role-id, token-id, current mode 
[assignment: additional security attributes, or none]]. 


FIAUSB.1.2 

The TSF shall enforce the following mies on the initial association of user 
security attributes with subjects acting on the behalf of users: [assignment: 
rules for the initial association of attributes ]. 


FIAUSB.1.3 

The TSF shall enforce the following rules goveming changes to the user 
security attributes associated with subjects acting on the behalf of users: 
[no changes of the security attributes are allowed during a session ]. 


Hierarchical to: 

No other components. 


Dependencies: 

FlAATD.l 


Application Note: The initial mies for the association of attributes to the subjects depend on 



the concrete implementation. Therefore, the assignment in FIA USB. 1.2 
is left to the specification and ST author. In any case it has to be ensured 
that the binding of attributes happens directly after the user (more 
precisely: the token of the user) has been identified and authenticated. 


692 6.6 Class FMT: Security Management 

693 6.6.1.1 Management of TSF data (FMT MTD) 

694 6.6.1.1.1 FMT MTD.1 Management of TSF data 

FMTMTD.l.l The TSF shall restrict the ability to \import, export and delete as depicted 

in Table 731 the [all TSF data ] to [roles that are associated with modes as 
depicted in Table 13], 

Hierarchical to: No other components 

Dependencies: FMTSMR.l 
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Application Note: 

FMTSMF.l 

The TOE shall control access to the TSF data to authorized roles within 
dedicated modes. This means that the TOE has a predefmed mode changes 
and within each mode only dedicated roles are allowed to manage the TSF 
data. The assignment of roles to modes is shown in Table 13. 


695 6.6.1.2 Management of security attributes (FMTMSA) 

696 6.6.1.2.1 FMT MSA.3: Static attribute initialisation 

FMTMSA.3.1 The TSF shall enforce the [vote counter access SFP, Information flow 


FMT_MSA.3.2 

control SFP 1 to provide [restrictive] default values for securitv attributes 
that are used to enforce the SFP. 

The TSF shall allow the [ nobody] to specify altemative initial values to 
override the default values when an object or information is created. 

Hierarchical to: 

No other components 

Dependencies: 

FMTMSA.1 

FMT SMR.1 


697 6.6.1.2.2 FMT MSA.1: Management of security attributes 

FMT MSA. 1 The TSF shall enforce the [vote counter access control SFP(s)\ to restrict 


Hierarchical to: 

the ability to [modify] the security attributes [ all security attributes] to [no 
role ]. 

No other components 

Dependencies: 

FDPACC.l 

FMTSMR.1 

FMT SMF.1 


698 6.6.1.2.3 FMT MSA.2 Secure security attributes 

FMT MSA.2.1 The TSF shall ensure that only secure values are accepted for [all security 


Hierarchical to: 

attributes and TSF data]. 

No other components 

Dependencies: 

FDPACC.l 

FMTMSA.1 

FMTSMR.1 

Application Note: 

The TOE shall ensure that only secure values are accepted for all security 
attributes. This is specifically (but not only) the case for all data that is 
imported from outside the scope of control of the TOE. 

This requirement specifically applies to the configuration data, token data 
and the software/firmware updates that must only be accepted and 
processed by the TOE if the attached signatures can be verified. 
lt is acknowledged that the possibility of the TOE to ensure that only 
secure values for TSF data in general are accepted is limited. 
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699 6.6.1.3 Security management roles (FMT SMR) 

700 6.6.1.3.1 FMT SMR. 1: Security roles 

FMT SMR. 1.1 The TSF shall maintain the roles [ 

• (de)configuratoi; 

• Vote counter operator ]. 

FMT SMR. 1.2 The TSF shall be able to associate users with roles. 

Flierarchical to: No other components 

Dependencies: F1AU1D.1 

701 6.6.1.4 Specification of Management Functions (FMT SMF) 

702 6.6.1.4.1 FMT SMF.l Specification of Management Functions 

FMT SMF. 1.1 The TSF shall be capable of performing the following management 

functions: [ 

• activation of a mode of operation (“change mode ”) 

• import election configuration data 

• export election configuration data 

• import token data , 

• import key store configuration data 

• export token data, 

• update firmware/software 

• export log, 

• erase configuration data, 

• erase counting data, configuration data and log, 

• export counting result, 

• export firmware/software, 

• perform selftest, 

• test vote counter function, 

• enter number of polling station or ballot box number, 

• enter / verify number of polling station or ballot box number 

• [assignment: additional management functions, or none]]. 

Flierarchical to: No other components 

Dependencies: No dependencies 

Application Note: lt should be noted that the access to the management functionality as 

defined in FMT SMF. 1 is restricted to certain administrative roles. The 
restriction of access is defined in the SFRs of the families FMT MOF (see 
below) and the SFRs for access control. 
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703 6.6.1.5 Management of functions in TSF (FMT MOF) 

704 6.6.1.5.1 FMT MOF.l Management of security functions behaviour 

FMT MOF. 1.1 The TSF shall restrict the ability to [modify the behaviour of\ the functions 

[all management functions'] to [nobody]. 

Hierarchical to: No other components 

Dependencies: FMTSMR. 1 

FMTSMF.l 

705 6.6.1.5.2 FMTMOF.l/Mode Management of security functions behaviour for the mode of 

706 operation 

FMTMOF.l.l The TSF shall restrict the ability to [change] the functions [mode of 

operation] to [roles and modes as depicted in Table 13]. 

Hierarchical to: No other components 

Dependencies: FMTSMR.l 

FMTSMF.l 

Application Note: The mode of operation for the TOE is an essential aspect of the access 

control policy of the TOE. Therefore, FMT MOF.l/Mode has been 
introduced in order to make sure that only users of authorized roles are 
allowed to change the mode. More details on the restrictions can be found 
in Table 13. 

707 6.7 Class FPT: Protection of the TSF 

708 6.7.1.1 TSF physical protection (FPT PHP) 

709 6.7.1.1.1 FPT PHP.2: Notification of physical attack 

FPT PHP.2.1 The TSF shall provide unambiguous detection of physical tampering that 

might compromise the TSF. 

FPT PHP.2.2 The TSF shall provide the capability to determine whether physical 

tampering with the TSF's devices or TSF's elements has occurred. 

FPT PHP.2.3 For [the vote counter and its casing], the TSF shall monitor the devices 

and e l e m e nts and notify [all roles] when physical tampering with the 
TSF's devices or TSF's elements has occurred. 

Hierarchical to: FPT PHP. 1 

Dependencies: FMTMOF.l 

Application Note: Based on the assumption that the vote counter operator is not trained in the 

detection of tampering, the self-protection mechanism of the TOE will 
detect intrusion and switch the TOE automatically into the mode 
“management”. The (de)configurator is allowed to print and export count 
results, export logs, configuration data, token data and firmware/software 
of the TOE for investigation. 
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710 6.7.1.1.2 FPT PHP.3: Resistance to physical attack 

FPTPHP.3.1 The TSF shall resist [ 

• physical tampering attacks 

• [assignment: physical tampering scenarios or none] 

to the [casing of the TOE [assignment: list of TSF elements or none] ] by 
responding automatically such that the SFRs are always enforced. 

Hierarchical to: No other components 

Dependencies: No dependencies 

711 6.7.1.2 Trusted recovery (FPT RCV) 

712 6.7.1.2.1 FPTRCV.3 Automated recovery without undue loss 

FPTRCV.3.1 When automated recovery from [assignment: list of failures/service 

discontinuities or none] is not possible, the TSF shall enter a maintenance 
mode where the ability to return to a secure state is provided. 

FPT_RCV.3.2 For [power blackout, [assignment: list offailures/service discontinuities or 

none ]\, the TSF shall ensure the return of the TOE to a secure state using 
automated procedures. 

FPTRCV.3.3 The functions provided by the TSF to recover trom failure or service 

discontinuity shall ensure that the secure initial state is restored without 
exceeding [assignment: quantification ] for loss of TSF data or objects 
under the control of the TSF. 

FPT RCV.3.4 The TSF shall provide the capability to determine the objects that were or 

were not capable of being recovered. 

Hierarchical to: No other components 

Dependencies: No dependencies 

Application Note: The concrete assignments in FPT RCV.3 are left to the ST author. When 

completing them, the ST author shall consider the fiinctional specification 
of the vote counter as well as security aspects (e.g. it might be helpful to 
define that the current user will have to get re-authenticated after a relevant 
failure). 

713 6.7.1.2.2 FPT RCV.4 Function recovery 

FPT RCV. 1.1 The TSF shall ensure that [all functions ] have the property that the 

function either completes successfully, or for the indicated failure 
scenarios, recovers to a consistent and secure state. 

Hierarchical to: No other components 

Dependencies: No dependencies 
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Application Note: Secure state in this context means that the TOE shall either résumé or abort 

the counting process. For the case that a function recovery in this sense is 
not possible the TOE shall fall to its mode “management”. In this way it 
can be ensured that the TOE never operates within an undefmed state. 


714 6.7.1.3 TSF self test (FPT TST) 

715 6.7.1.3.1 FPT TST.l: TSF testing 

FPT TST.l.l The TSF shall run a suite of self tests [ during initial start-up, periodically 

during normal operation, at the request of the authorised user, at the 
conditions [assignment: conditions under which self test should occur or 
none]] to demonstrate the correct operation of fthc TSF1 . 

FPT TST.1.2 The TSF shall provide authorised users with the capability to verify the 

integrity of [ 

• loss, 

• confïsuration data, 

• token data, 

• software/firmware of the TOE 

• fassisnment: parts of the TOE or nonell. 

FPT TST.1.3 The TSF shall provide authorised users with the capability to verify the 

integrity of [ 

• the internat hardware, 

• the internat software/firmware 

• theprinting unit, 

• the casing, 

• the interfaces, 

• fassisnment: parts ofTSFor nonell . 


Hierarchical to: 


No other components 


Dependencies: 


No dependencies 


Application Note: The verification of the integrity of software/firmware may be implemented 

in software or hardware like a Trusted Platform Module (TPM). Thi s 
implementation is part of the TOE and therefore part of the evaluation of 
the TOE. Verification of software/firmware relies on the integrity of the 
hardware. Therefore the mechanism of verifying the integrity of the 
hardware needs to be reliable and trustworthy. 


716 6.7.1.4 Integrity of exported TSF data (FPT FTI) 

717 6.7.1.4.1 FPT ITI.1 Inter-TSF detection of modification 


FPT ITI.1.1 The TSF shall provide the capability to detect modification of all TSF data 

during transmission between the TSF and another trusted 1T product within 
the following metric: [assignment: a defined modification metric\. 
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FPT ITI.1.2 The TSF shall provide the capability to verify the integrity of all TSF data 

transmitted between the TSF and another trusted IT product and perform 
[switch the TOE into the mode “blocked ”] if modifications are detected. 

Hierarchical to: No other components 

Dependencies: No dependencies 

Application Note: Electoral data, referendum data, the log file and the counting result are data 

can be exchanged between the TOE and other digital products that provide 
this data or related to the log file where they are stored to. In the context of 
FPT ITl. 1 these digital products are trusted 1T products and it has to be 
ensured that modification on the data during the transmission will be 
detected. 

718 6.7.1.5 Replay detection (FPT RPL) 

719 6.7.1.5.1 FPT RPL. 1: Replay detection 

FPTRPL.l.l The TSF shall detect replay for the following entities: [ ballot papers that 

have been scanned more than once in the same counting sequence . 

FPT RPL. 1.2 The TSF shall perform [put the ballot paper into the dedicated output tray ] 

when replay is detected. 

Hierarchical to: No other components 

Dependencies: No dependencies 

720 6.7.1.6 Fail secure (FPT FLS) 

721 6.7.1.6.1 FPT FLS.l: Failure with preservation of secure state 

FPT FLS.l.l The TSF shall preserve a secure state when the following types of failures 

occur: [ 

• the self-test detects an error or manipulation, 

• the self-protection detects a manipulation 

• [assignment, other failures to be defined by the ST author] 

]• 

Hierarchical to: No other components 

Dependencies: No dependencies 

Application Note: The secure state mentioned in the SFR FPT FLS.l refers to the mode 

“management” within the life-cycle model. 

722 6.7.1.7 Time stamps (FPTSTM) 

723 6.7.1.7.1 FPT STM.l Reliable time stamps 

FPT STM. 1.1 The TSF shall be able to provide reliable time stamps. 

Hierarchical to: No other components 
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Dependencies: No dependencies 

724 6.8 Class FRU: Resource utilisation 

725 6.8.1.1 Fault tolerance (FRUFLT) 

726 6.8.1.1.1 FRU_FLT.2 Limited fault tolerance 

FRUFLT.2.1 The TSF shall ensure the operation of all the TOE's capabilities when the 

following failures occur: [assignment: list of type offailures]. 

Hierarchical to: FRUFLT. 1 

Dependencies: FPTFLS.l 

727 6.9 Class FTA: TOE access 

728 6.9.1.1 Session locking and termination (FTA SSL) 

729 6.9.1.1.1 FTASSL.3 TSF-initiated termination 

FTASSL.3.1 The TSF shall terminate an interactive session after a [ assignment: time 

interval of user inactivity ]. 

Hierarchical to: No other components 

Dependencies: No dependencies 

Application Note: The assignment in FTA SSL.3.1 allows specifying the time after which the 

TOE shall end the session with a user. This time interval highly depends on 
the concrete implementation of the TOE and is therefore left to the 
specification and ST author. 

730 

731 6.9.1.1.2 FTA SSL.4 User-initiated termination 

FTA SSL.4.1 The TSF shall allow user-initiated termination of the user's own interactive 

session. 

Hierarchical to: No other components 

Dependencies: No dependencies 

732 6.9.1.2 TOE access banners (FTA TAB) 

733 6.9.1.2.1 FTA TAB. 1 Default TOE access banners 

FTA TAB.l.l Before establishing a user session, the TSF shall display an advisory 

warning message regarding unauthorised use of the TOE. 

Hierarchical to: No other components 

Dependencies: No dependencies 


Bijlage: Protection Profile stemmenteller 


58 



Vote Counter-PP 


734 6.9.1.3 TOE access history (FTATAH) 

735 6.9.1.3.1 FTA TAH.l TOE access history 

FTA TAH. 1.1 Upon successful session establishment for a (de)configurator,, the TSF 

shall display the [ date, time, method, location] of the last successful session 
establishment to the user. 

FTA TAH. 1.2 Upon successful session establishment for a (de)configurator,, the TSF 

shall display the \date, time, method, location 1 of the last unsuccessful 
attempt to session establishment and the number of unsuccessful attempts 
since the last successful session establishment. 

FTA TAH. 1.3 The TSF shall not erase the access history information from the user 

interface without giving the user an opportunity to review the information. 

Hierarchical to: No other components 

Dependencies: No dependencies 

Application Note: The TOE access history only applies to logins of a (de)configurator. Each 

(de)configurator shall be presented the last successful and unsuccessful 
login attempts of this administrative role. 

736 6.9.1.4 TOE session establishment (FTATSE) 

737 6.9.1.4.1 FTA TSE.l TOE session establishment 

FTATSE.l.l The TSF shall be able to deny session establishment based on [the 

assignment of mies to dedicated modes as outlined in Table 14\. 

Hierarchical to: No other components 

Dependencies: No dependencies 

Application Note: The interaction of the 

738 



739 Table 14: TSF managing subjects and the modes they have access to the TOE 

740 
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741 6.10 Security Assurance Requirements for the TOE 

742 The minimum Evaluation Assurance Level for this Protection Profile is EAL 4 augmented by 

743 ALC_DVS.2, AVA_VAN.5 and the use of the explicit component ALC_DEL.2. 

744 The following table lists the assurance components which are therefore applicable to this PP. 

745 


Assurance Class 

Assurance Component 

Development 

ADVARC.l 


ADVFSP.4 


ADVIMP.l 


ADVTDS.3 

Guidance documents 

AGDOPE.l 


AGDPRE.l 

Life-cycle support 

ALCCMC.4 


ALCCMS.4 


ALCDEL.2 


ALCDVS.2 


ALCLCD.l 


ALCTAT.l 

Security Target Evaluation 

ASECCL.l 


ASEECD.l 


ASE1NT. 1 


ASEOBJ.2 


ASEREQ.2 


ASESPD.l 


ASETSS. 1 

Tests 

ATECOV.2 


ATEDPT. 1 


ATE_FUN. 1 


ATE1ND.2 

Vulnerability Assessment 

AVA VAN.5 


746 Table 15: Assurance Requirements 
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747 6.11 Security Requirements rationale 

748 6.11.1 Security Functional Requirements rationale 

749 6.11.1.1 Fiilfilment of the Security Objectives 

750 This chapter proves that the set of security requirements (TOE) is suited to fulfil the security 

751 objectives described in chapter 4 and that each SFR can be traced back to the security objectives. At 

752 least one security objective exists for each security requirement. 



O.Process 

O.lntegrity 

O.Log 

O.Management 

O.DataExchange 

O.Selfprotection 

O.AccessControl 

FAUARP.l 

X 





X 


FAUGEN.l 



X 





FAU_GEN.2 



X 





FAU_SAA. 1 

X 





X 


FAUSTG.1 



X 





FAUSTG.4 



X 





FC S C OP. 1 


X 






FDPACC.2 







X 

FDPACF.l 







X 

FDPDAU.l 


X 

X 





FDP FPC.1 

X 







FDP1FC.2 






X 


FDPIFF.l 






X 


FDPITT.2 






X 


FDPITT.4 






X 


FDPSDI.2 


X 

X 





FIAAFL.l 







X 

FlAATD.l 







X 

F1AU1D.2 







X 

F1A_UAU.2 







X 

FIAUSB.l 







X 

FMTMTD.l 




X 

X 
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O.Process 

O.lntegrity 

O.Log 

O.Management 

O.DataExchange 

O.Selfprotection 

O.AccessControl 

FMT_MS A. 1 

FMT_MSA.2 




X 









X 


FMT_MSA.3 




X 




FMTSMR.1 







X 

FMTMOF.l 




X 




FMTMOF.l/Mode 







X 

FMTSMF.l 




X 




FPTPHP.2 






X 


FPTPHP.3 

FPTRCV.3 






X 


X 

X 






FPTRCV.4 

FPTTST.l 

X 







X 





X 


FPTJTl.1 





X 



FPTRPL. 1 

X 

X 






FPTFLS.l 

X 





X 


FPTSTM.l 



X 





FRUFLT.2 

X 





X 


FTASSL.3 







X 

FTASSL.4 







X 

FTATAB.l 







X 

FTATAH. 1 







X 

FTATSE.l 







X 


753 Table 16: Fulfïlment of Security Objectives 

754 The following paragraphs contain more details on this mapping. 

755 6.11.1.1.1 O.Process 

756 O.Process is met by a combination of the following SFRs: 
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757 

758 

759 

760 

761 

762 

763 

764 

765 

766 

767 

768 

769 

770 

771 

772 

773 

774 

775 

776 

777 

778 

779 

780 

781 

782 

783 

784 

785 

786 

787 

788 

789 

790 

791 

792 

793 

794 

795 

796 

797 

798 

799 

800 
801 
802 


• FDP_FPC.1 defines how the TOE shall process the ballot papers. Thus, this SFR ensures that 
the overall process of the scanning is performed in a way that meets the requirements of 
O.Process. 

• FAU_ARP.1 and FAU_SAA.1 should ensure that security relevant events that could have an 
impact to the secure counting process will be detected. 

• FPT_RCV.3 defines the requirements for automated recovery in case of certain errors during 
the counting process and therefore supports the secure counting process. 

• FPTRCV.4 ensures that the TOE is able to recover to a secure state in case processing 
exceptions are encountered and therefore supports a robust counting process. 

• FPT_TST.1 defines a self test that helps to ensure that the security features of the TOE 
(including the counting functionality) are working correctly. 

• FPT_RPL.1 defines the requirement that the TOE shall detect replayed ballot paper and 
therewith supports the secure counting process. 

• FPT_FLS.1 and FRU_FLT.2 define how the TOE shall react in case of errors and support 
that the security functionality will work as specified. 


6.11.1.1.2 O.lntegrity 

O.lntegrity is met by a combination of the following SFRs: 

• FDP_DAU.1 provides the functions to verify integrity and authenticity of the log and counting 
result. 

• FDP SDI.2 ensures that it the integrity of the counting data is monitored and that the vote 
counter will change its mode to “management” in case of integrity failures. 

• FPT_RCV.3 requires that the TOE is able to recover to a secure state without loss of data or at 
least the possibility to detect the data it was not capable to restore. This ensures the integrity of 
the counting in case of unexpected power blackouts. 

• FPT_RPL.1 requires that the TOE is able to detect ballot papers that already have been 
scanned within in the same counting sequence. This contributes to the integrity of the counting 
result. 

• FCS_COP.l provides the functionality of hashing and verification of digital signatures to 
verify the integrity of imported data. The hashing and verification of digital signatures allows 
the detection of any manipulation of the imported and signed data and contributes therefore to 
the protection of the integrity of this data. 

6.11.1.1.3 O.Log 

O.Log is met by a combination of the following SFRs: 

• FAU_GEN.1 and FAU_GEN.2 define that a log file must be generated and define the records 
that shall be audited. 

• FAU_STG1 ensures that the audit records cannot be manipulated and deleted from 
unauthorised roles and contributes therefore to the availability of the log. 

• FAU_STG4 defines the behaviour if the audit trail is tuil and ensures that no audit data is lost. 

• FDP_DAU.1 provides the iunctions to verify integrity and authenticity of the log and counting 
result and thus the possibility to ensure that the log and counting result have not been 
manipulated. 

• FDP_SDI.2 defines requirements on the integrity protection for data, including the log file. 

• FPT_STM.1 provides the time that can be used by the audit functionality to provide the 
events with a timestamp. Those timestamps allow the tracing of entities and their actions with 
the vote counter 
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803 

804 

805 

806 

807 

808 

809 

810 
811 

812 

813 

814 

815 

816 

817 

818 

819 

820 
821 
822 

823 

824 

825 

826 

827 

828 

829 

830 

831 

832 

833 

834 

835 

836 

837 

838 

839 

840 

841 

842 

843 

844 

845 

846 

847 

848 

849 


6.11.1.1.4 O.Management 

O.Management is met by a combination of the following SFRs: 

• FMT_MTD.1 defmes the roles that are allowed to manage TSF data and defmes the actions 
those roles are allowed to perform with the TOE. This ensures that the access should be 
limited to the functionalities for which the role is authorized. 

• FMT MSA.1 ensures that no role should be able to change the security attributes and can 
cause vulnerabilities of the TOE due to configuration errors or attacks. 

• FMT_MSA.3 defmes the initialization attributes and that no role should be able to change the 
default values. This ensures that the TOE always uses valid default values on its start-up. 

• FMT MOF. 1 ensures that a role cannot change the behaviour of security functions. Similar to 
FMT MS A. 1 this should ensure that misconfiguration do not lead to any vulnerabilities of the 
TOE. 

• FMT_SMF.1 defmes the management functions that the TOE shall provide. This ensures that 
the TOE does not provide any functionality that is not necessary and could lead to a lack of 
security. 

6.11.1.1.5 O.DataExchange 

O.DataExchange is met by a combination of the following SFRs: 

• FMT_MTD.1 defmes the roles that are allowed execute data exchange. This ensures that only 
allowed roles are able to import or export data and prevents that other roles may use this 
functionality to import/export data. 

• FPT_ITI.1 defmes the requirements for detections of modifications when data is submitted 
between the TOE and another trusted 1T product (which is the core functionality as required 
by O.DataExchange). 

6.11.1.1.6 O.Selfprotection 

O.Selfprotection is met by a combination of the following SFRs: 

• FAUARP.l ensures that the TOE notifies the user if it detects a security violation. This 
should ensure that the user is informed in case of a potential security violation. 

• FAU_SAA.1 requires that the TOE is able to analyze its audited events and should therefore 
be capable to detect a potential security violation based on these records. 

• FDP ITT.2 and FDP ITT.4 ensure secure handling of data when transmitted between 
physically separated parts of the TOE. 

• FMT MSA.2 ensures the acceptance of secure values. This is specifically relevant when data 
is imported from outside the scope of control of the TOE and therewith adds to the self 
protection capabilities as required by this objective. 

• FPT PHP.2 defmes the requirements for the physical protection that the TOE must provide 
and the behaviour of the TOE if it detects tampering. This should ensure that a physical 
tampering attack to the TOE its hardware and its casing will lead to an action defmed in 
FAU PHP. 3 and FAU ARP. 1. 

• I PT Pfl P.3 defmes an automated response to tampering scenarios. This should ensure that 
the TOE will be able to react in an adequate manner if it detects physical tampering attacks 

• FPT_TST.1 defmes allowed self-testing functionality to check the correct working of the 
TOE. Such a self-test should be able to detect manipulation of hardware, software, data, the 
connection of fake devices and the manipulation of the power supply. 

• FPT_FLS.1 defmes that in case of errors or tampering the TOE will switch to a secure state 
(the mode to “management”). 

• FRUFLT.2 ensures that the TOE can react in tolerance to a number of well-defmed error 
States. This enhances the self-protection capabilities of the TOE. 
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850 • FDP IFC.2 and FDP IFF.1 ensure that sensitive information is only transferred between 

851 those parts of the TOE that actually need it. This helps to protect the TOE against attacks that 

852 try to recover sensitive information. 

853 6.11.1.1.7 O.AccessControl 

854 O.AccessControl is met by a combination of the following SFRs: 

855 • FDP_ACC.2 and FDP_ACF.1 define the vote counter access SFP. This SFP ensures that only 

856 the defmed roles within dedicated modes should have access to the TOE and to the 

857 functionality. 

858 • FIA AFL.1 ensures that the authentication mechanism should be protected against brute force 

859 attacks. 

860 • FIA_ATD.1 defines the security attributes to be assigned to a token. These attributes are 

861 necessary to implement the access policies of roles to fimctions of the TOE. 

862 • FIA UAU.2 and FIA UID.2 requires th t every entity must be successfully authenticated 

863 and identified before that entity can perform an action with the TOE. This should ensure that 

864 an entity is not able to perform an action without permission. 

865 • FIA_USB.1 defines the mapping between security attributes and subjects to enforce the access 

866 SFP. 

867 • FMT_SMR.1 defines the security roles used by the TOE. 

868 • FMTMOF. 1/Mode ensures that changing the mode of operation is limited to certain roles 

869 and based on the current mode. 

870 • FTA_SSL.3, FTA_SSL.4 and FTA_TSE.1 require and define a session based access control 

871 that is used to grant access to the TOE. 

872 • FTA_TAB.1 ensures that the TOE presents the user with the access banners that are defmed in 

873 O.AccessControl. 

874 • FTATAH.l ensures tha the TOE presents the (de)configurator with information about their 

875 last successful and unsuccessful login attempts after they successfully logged in 

876 

877 6.11.1.2 Fulfilment of the dependencies 

878 The following table summarises all TOE functional requirements dependencies of this PP and 

879 demonstrates that they are fulfilled. 


SFR 

Dependencies 

Fulfilled by 

FAUGEN.l 

FPT STM. 1 Reliable time stamps 

FPTSTM.l 

FAUSTG.1 

FAU GEN. 1 Audit data generation 

FAUGEN.l 

FAUSTG.4 

FAU STG. 1 Protected audit trail storage 

FAUSTG.1 

FDPACC.2 

FDP ACE 1 Security attribute based access control 

FDPACF.l 

FDP IFC.2 

FDP IFF. 1 Simple security attributes 

FDPIFF.1 

FDPIFF.1 

FDP 1FC. 1 Subset information flow control 

FDP1FC.2 

FMT MSA.3 Static attribute initialisation 

No component. 
Justification: The 
information flow 
control policy 
specified in 
FDPIFF.1 and 
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880 


SFR 

Dependencies 

Fulfilled by 



FDP1FC.2 does 
not require to 
manage any 
security attributes. 

FDPITT.2 

[FDPACC. 1 Subset access control, or 

FDP IFC.1 Subset information flow control] 

Both (depending 
on the 

implementation) 

FDPITT.4 

[FDP ACC. 1 Subset access control, or 

FDP 1FC. 1 Subset information flow control] 

FDP 1TT.2 Transmission separation by attribute 

FDP ACC.2 and 
FDP IFC.2 
(depending on the 
implementation), 
FDPITT.2 

FDPACF. 1 

FDP ACC.1 Subset access control 

FDPACC.2 

FMT MSA.3 Static attribute initialisation 

FMT_MSA.3 

FIAAFL. 1 

F1A UAU. 1 Timing of authentication 

FIAJJAU.2 

F1A_UAU.2 

F1A UID.1 Timing of identification 

FIAUID.2 

FIAUSB.l 

F1A ATD.1 User attribute defmition 

FIAATD.l 

FMTMTD.l 

FMT MTD.1 Management ofTSF data 

FMTMTD.l 

FMT SMR. 1 Security roles 

FMTSMR.1 

FMT_MSA.3 

FMT MSA. 1 Management of security attributes 

FMT_MS A. 1 

FMT SMR. 1 Security roles 

FMTSMR.1 

FMT_MSA. 1 

FDP ACC.1 Subset access control 

FDPACC.2 

FMT MSA. 1 Management of security attributes 

FMT_MS A. 1 

FMT SMR. 1 Security roles 

FMTSMR.1 

FMT_MSA.2 

FDP ACC.1 Subset access control 

FDPACC.2 

FMT MSA. 1 Management of security attributes 

FMT_MS A. 1 

FMT SMR. 1 Security roles 

FMTSMR.1 

FMTSMR.1 

F1A UID.1 Timing of identification 

FIAUID.1 

FMTMOF.l 

FMT SMR. 1 Security roles 

FMTSMR.1 

FMT SMF. 1 Specification of Management Functions 

FMTSMF.l 

FMTMOF.l 

FMT SMR. 1 Security roles 

FMTSMR.1 

FMT SMF. 1 Specification of Management Functions 

FMTSMF.l 

FPTPHP.2 

FMT MOF. 1 Management of security functions behaviour 

FMTMOF.l 

FPTRCV.3 

AGD OPE.1 Operational user guidance 

AGDOPE.l 


Table 17: SFR Dependencies 
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881 6.11.1.3 Justification for missing dependencies 

882 6.11.1.4 Justification for selection of assurance level 

883 EAL4 permits a developer to maximise assurance gained from positive security engineering 

884 based on good commercial development practices. It is also the highest assurance level that 

885 enables the use of Standard components (hardware and software). EAL4 is the highest level at 

886 which it is likely to be economically feasible to retrofit to an existing product line. It is 

887 applicable in those circumstances where developers or users require a moderate to high level 

888 of independently assured security in conventional commodity TOEs, and there is willingness 

889 to incur some additional security-specific engineering costs. 

890 An EAL4 evaluation provides, in addition to EAL3, an analysis supported by a complete interface 

891 specification, a description of the basic modular design of the TOE, and a subset of the 

892 implementation. Testing is supported by a vulnerability analysis (also using the implementation 

893 representation), demonstrating resistance to penetration attackers with an Enhanced-Basic attack 

894 potential. Assurance is also provided through additional automated configuration management. 

895 In addition to the measures that are included in the EAL4 package, three further components have 

896 been chosen in order to address dedicated aspects: 

897 The assurance component ALCDVS.2 provides evidence that security measures implement sufficiënt 

898 protection. This component will help assuring that security requirements are addressed in the design. 

899 The explicit assurance component ALCDEL.2 has been designed and selected in order to express a 

900 certain need in the context of the development and production of the vote counter. In Standard 

901 evaluations it falls into the responsibility of the developer to ensure that each instance of the TOE that 

902 is produced matches the requirements trom the specification and evaluation. In the context of the 

903 development of the criteria for the vote counter it became evident that this would not be sufficiënt in 

904 this context. Rather, a need has been identified that each instance of the TOE is checked after 

905 production in order to ensure that it needs the criteria. While this assurance requirement represents a 

906 significant effort it has been found that this is the only way to ensure that each and every vote counter 

907 that is used is secure and meets the requirements. 

908 The augmentation by AVA VAN.5 has been chosen to provide confidence that the TOE will resist 

909 sophisticated attacks. 

910 6.11.2 Security Assurance Requirements rationale 

911 6.11.2.1 Dependencies of assurance components 

912 The dependencies of the assurance requirements taken trom EAL 4 are fulfilled automatically. The 

913 augmentation by ALC DEL.2, ALC DVS.2 and AVA VAN.5 does not introducé additional assurance 

914 components that are not contained in EAL 4. 
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915 7 Appendix 

916 7.1 Glossary 




Authenticity 

Property that an entity is what it claims to be. 

Authority for 
investigation 

See chapter 3.1 

Ballot paper 

Special paper that is used to print the choices. 

Choice 

See chapter 3.2 

Confidentiality 

The property that information is not made available or disclosed to 
unauthorised individuals, entities, or processes. 

Configuration data 

See chapter 3.2 

EAL 

Evaluation Assurance Level 

Electoral committee 

See chapter 3.1 

Ephemeral vote 
printer data 

See chapter 3.2 

Integrity 

Property that sensitive data has not been modified or deleted in an 
unauthorised and undetected marnier. 

Logs 

See chapter 3.2 

Maintenance authority 

See chapter 3.1 

TOE 

Target of Evaluation -set of software, filmware and/or hardware possibly 

Token 

In this context a hardware component that is used to switch between the 
modes and to activate the TOE. 

Token data 

See chapter 3.2 

Vote counter reviewer 

See chapter 3.1 

Voter 

See chapter 3.1 
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